Метод, который мы будем тестировать, это loginметод на LoginService. Поскольку этот метод зависит от UserDAO, нам нужно создать для него макет. В этом уроке мы будем использовать фреймворк jmockit. Прежде чем мы начнем писать какой-либо тестовый код, давайте рассмотрим некоторые важные моменты, касающиеся инфраструктуры jmockit.

JMockit

Большинство фальшивых фреймворков (JMock, EasyMock и т. Д.) Основаны на java.lang.Proxyобъекте. Они создают прокси-объект, основанный на интерфейсе, который вы предоставляете для инъекции в тестируемый объект. Разработчик сообщает прокси-серверу, что ожидать и что возвращать, когда ожидание оправдано. Есть две проблемы с этим:

1. Требуется интерфейс. Не поймите меня неправильно, программирование интерфейсов — это хорошо, но не все требует интерфейса. У EasyMock есть расширение, которое обрабатывает классы без интерфейса, но может быть затруднительно иметь два разных EasyMockобъекта, включенных в ваш тестовый класс, чтобы делать в основном одно и то же.
2. Требуется введение зависимости какого-либо вида. Не поймите меня неправильно, я люблю Spring и использую его в своем текущем проекте. Но что, если вы не хотите, чтобы Spring управлял всем ? Вы не можете смоделировать объект, созданный в вашем методе. Единственный способ использовать фиктивные объекты — это управлять экземпляром объекта в другом месте (обычно на фабрике).

jmockit решает эти две проблемы, используя возможность переопределения. Если вы не знакомы с новой возможностью переопределения классов в JDK 1.5+, то, по сути, она позволяет программно сказать JVM переназначить класс в другой файл классов. Поэтому, когда вы создаете макет с помощью jmockit, вы создаете новый класс, которым JVM заменит зависимый класс.

Контрольный пример

Итак, теперь, когда мы немного знаем о TestNG и jmockit, давайте начнем разбирать наш тестовый пример. Для начала, создайте пустой тестовый набор TestNG с соответствующим импортом:

import org.testng.annotations.*;

public class LoginServiceTest {

}

Обратите внимание, что класс не расширяет какой-либо класс и не реализует интерфейс. Это потому, что TestNG не требует этого. Мы будем диктовать все этапы жизненного цикла с помощью аннотаций. Как мы уже отмечали ранее, loginметод зависит от UserDAO. Поэтому давайте создадим setupMocksметод, который будет запускаться перед каждым тестом. Этот setupMocksметод создаст все необходимые макеты, которые нам нужны, и соответственно добавит их.

import mockit.Expectations;

import org.testng.annotations.BeforeTest;
import org.testng.annotations.Test;

public class LoginServiceTest extends Expectations {
	
	private LoginServiceImpl service;
	UserDAO mockDao;
	
	@BeforeTest
	public void setupMocks() {
		service = new LoginServiceImpl();
		service.setUserDao( mockDao );
	}
}

Давайте рассмотрим, что у нас в вышеприведенном классе. У нас есть два необходимых импорта для этого тестового примера mockit.Mockit(основная утилита для jmockit) и org.testng.annotations.*для импорта необходимых аннотаций TestNG, которые мы будем использовать. Мы объявили два объекта, которые нас интересуют: тестируемый сервис и фиктивный DAO для инъекций. Обратите внимание, что LoginService является частной, а UserDAO — нет. jmockit автоматически создаст фиктивный объект для mockDao для любых не приватных полей.

Далее у нас есть наш setupMocksметод. Это @BeforeTestаннотация TestNG . Это говорит TestNG запускать этот метод один раз перед каждым тестом. Это даст нам свежий экземпляр и пробную версию для тестирования, так что нам не придется заниматься какой-либо очисткой, которая может потребоваться. В нашем setupMocksметоде мы создаем фиктивный DAO, вызывая Mockit.setUpMock()метод jmockit и передавая ему наш интерфейс. Затем мы создаем экземпляр нашего сервиса для тестирования и, наконец, внедряем фиктивный объект в нашу реализацию. Если это выглядит как EasyMock, так и должно быть. Использование jmockit и EasyMock очень похоже на использование интерфейсов. Когда вы используете классы, использование отличается.

Следующим шагом является создание нашего фактического метода тестирования. В нашем методе тестирования мы хотим протестировать следующий сценарий:

Даже с помощью самого базового метода, который мы хотим протестировать выше, есть ряд различных сценариев, которые требуют тестирования. Мы начнем с «радужного» сценария, передавая два значения и возвращая пользовательский объект. Ниже приведен обновленный тест с нашим новым методом тестирования.

...
	/**
	 * This method will test the "rosy" scenario of passing a valid 
         * username and password and retrieveing the user. Once the user 
         * is returned to the service, the service will return true to 
         * the caller.
	 */
	@Test
	public void testRosyScenario() {
		User results = new User();
		String userName = "testUserName";
		String password = "testPassword";
		String passwordHash = 
                     "�Ӷ&I7���Ni=.";

		invokeReturning( 
                     mockDao.loadByUsernameAndPassword( userName, 
                                                        passwordHash ), 
                     results );
		endRecording();

		assert service.login( userName, password ) : 
                       "Expected true, but was false";
	}
...

Итак, давайте рассмотрим код выше. Мы начинаем с нашей аннотации @Test. Это говорит TestNG, что это метод тестирования. Оказавшись в методе, мы создаем ожидаемый результат нашего вызова DAO, результаты. В этом случае наш метод просто проверит, был ли возвращен объект, поэтому нам не нужно заполнять наш пользовательский объект чем-либо, нам просто нужен пустой экземпляр. Затем мы объявляем значения, которые будем передавать в наш сервисный вызов. Хэш пароля может застать вас врасплох. Хранить пароли в виде простого текста считается небезопасным, поэтому наш сервис сгенерирует хеш-пароль MD5, и это значение будет значением, которое мы передадим в наш DAO.

После объявления различных переменных, следующий вызов:

invokeReturning( 
     mockDao.loadByUsernameAndPassword( userName, passwordHash ), 
     results );

сообщает jmockit, что метод loadByUsernameAndPasswordдолжен вызываться со значениями, ранее объявленными в userNameи passwordHash. Когда это произойдет, верните значение results. Следующая строка:

endRecording();

говорит jmockit, что мы закончили записывать ожидания для этого теста. В этот момент jmockit автоматически переходит в режим воспроизведения. Наконец, мы выполняем фактический «тест», выполняя тестируемый метод loginи утверждая, что это правда. Если это не так, мы представляем сообщение. TestNG рассматривает прохождение теста, если не выдается никаких исключений. Если исключение выдается из метода, который объявлен тестом, тест завершается неудачей.

Для запуска нашего теста нам нужно настроить еще одну вещь. Нам нужно сообщить JVM, что у нас будет запущен агент Java. Для этого щелкните правой кнопкой мыши LoginServiceTest, выберите «Запуск от имени» -> «Открыть диалоговое окно выполнения». Слева выберите TestNG. Вверху нажмите на новый значок. В новой области справа введите LoginServiceTest в поле Class. Нажмите вкладку Аргументы в верхней части. В поле VM Arguments введите следующее (где
это полный путь к папке lib вашего проекта):

-javaagent:
 /jmockit.jar

Осталось только нажать Run. Какая? Тест не удался ?! Это потому, что мы еще не реализовали метод, который тестируем. Код для этого ниже.

import java.security.MessageDigest;
import java.security.NoSuchAlgorithmException;


public class LoginServiceImpl implements LoginService {
	UserDAO userDao;

	public void setUserDao(UserDAO userDao) {
		this.userDao = userDao;
	}
	
	public boolean login(String userName, String password) {
        boolean valid = false;
        try {
             String passwordHash = null;
             MessageDigest md5 = MessageDigest.getInstance("MD5");
             md5.update(password.getBytes());
             passwordHash = new String(md5.digest());

             User results = 
                  userDao.loadByUsernameAndPassword(userName, passwordHash);
             if(results != null) {
                  valid = true;
             }
        } catch (NoSuchAlgorithmException ignore) {}
		
        return valid;
   }
}

Вывод

Как видите, TestNG предоставляет надежный набор функций, который не чужд кому-то, кто привык к стилям юнит-тестов JUnit. Во второй части этого руководства мы проведем рефакторинг LoginService, чтобы лучше использовать инфраструктуру jmockit и создадим дополнительные тесты, которые мы можем организовать с помощью TestNG. До скорого!

Первоначально опубликовано на http://www.michaelminella.com/testing/unit-testing-with-testng-and-jmockit.html.