При написании тестов, даже самых простых, зачастую используются тестовые объекты. Например в статье про основные возможности JUnit я регулярно использовал следующую конструкцию:
|
1
2
|
String[] expected = {"T", "E", "S", "T"};
String source="T:E:S:T";
|
Что не совсем хорошо: во-первых, это нарушает принцип DRY — Don’t Repeat Yourself (не повторяй себя); во-вторых, если б тестовые объекты были бы хоть немногим сложнее, их регулярное (пере-) создание вылилось бы в полный кошмар. Представьте себе, если бы Вы в каждом тестовом методе писали такое (осторожно, говнокод):
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
|
Organization organization = new Organization();
organization.setId(1L);
organization.setActive(true);
organization.setAddress("Test city, Test street");
organization.setBankName("Test bank");
organization.setBic("12345678987");
organization.setCode("TESTORG");
organization.setContact("Test von Testoff");
organization.setCorrespondentAccount("034009100280477");
organization.setName("Test organization");
organization.setPhones("+70952320829");
organization.setTin("987654321");
organization.setTransactionalAccount("775082001900320");
organization.setTrc("192837465");
Office expected = new Office();
expected.setId(2L);
expected.setOrganization(organization);
expected.setCode(123);
expected.setName("Test branch");
expected.setManagerName("Test Testovich");
expected.setFirstAddress("Default city");
expected.setSecondAddress("Mordor");
expected.setPayableCode("TBP");
expected.setReceivableCode("TBR");
|
Ужасно! Представляете, 80% содержимого теста было бы простым созданием одних и тех же объектов. А уж когда эти объекты меняются, это был бы просто кошмар с переписыванием тестов.
Впрочем для этой проблемы в JUnit есть решение, которое позволяет удобно подготовливать окружение для тестов.
Подготовка
Возьмём код из примера основной функциональности JUnit и скопируем класс StringUtilsTest в StringUtilsSetupTest
Before/After
Любой public void метод, с аннотацией @Before будет вызван автоматически перед запуском каждого теста (то есть столько раз, сколько в классе
тестов). Традиционно такой метод называют setUp :
|
1
2
3
4
|
@Before
public void setUp() {
//Do setup here
}
|
Используя эту возможность, перенесём создание тестовых данных в метод setUp():
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
|
private String testString;
private String[] testArray;
@Before
public void setUp() {
testString = "T:E:S:T";
testArray = new String[] {"T", "E", "S", "T"};
}
@Test
public void testToArray() {
assertArrayEquals("Wrong array", testArray, StringUtils.toArray(testString, ':'));
assertNull(StringUtils.toArray(null, ':'));
//Don't uncomment next line - it will fail
//assertEquals(testArray, StringUtils.toArray(testString, ':'));
}
@Test
public void testJoinArray() {
assertEquals(testString,StringUtils.joinArray(testArray, ':'));
assertNull(StringUtils.joinArray(null, ':'));
}
// Unchanged methods are not shown.
}
|
Строку и массив, используемые в тестах, я вынес в члены класса и присваиваю им значение перед запуском каждого теста. Теперь, когда мне надо будет изменить тестовые данные, я смогу это сделать в одном месте — в функции setUp() и все остальные тесты, очевидно, будут использовать новые данные.
В случае, если бы я использовал какой-либо большой объект или объект, требующий какой-нибудь обработки после теста (закрытия файла, завершения транзакции, итд.), можно использовать аннотацию @After . Эта аннотация так же требует public void метод, который будет вызван после каждого теста. Традиционно такой метод называют tearDown:
|
1
2
3
4
|
@After
public void tearDown() {
//Do something
}
|
В моём примере трудно найти полезное применение этому функционалу, но почему-бы не сбрасывать после каждого теста тестовую строку?
|
1
2
3
4
|
@After
public void tearDown() {
testString=""; //Not very useful, but good enough for the example.
}
|
BeforeClass/AfterClass
Хороший, годный программист в этом месте спросит: «А зачем вообще перед каждым методом инициализировать строку? Почему нельзя обойтись одним разом, ведь строка не меняется?» и будет прав. Обычно аннотации @Before/@After используют для тех тестовых данных, которые изменяются в ходе теста и, следовательно, требуют восстановления исходных значений.
Для значений, которые достаточно проинициализировать один раз или инициализация которых слишком медленна, чтобы делать это перед каждым тестом, предусмотрены аннотации @BeforeClass/@AfterClass . Методы, которые ими можно аннотировать, должны быть статическими, а поэтому работать они могут только с статическими членами класса. Я мог бы сделать переменные testString и testArray статическими, но в иллюстративных целях лучше заведу
новую тестовую переменную, с помощью которой проверю, как разбираются на массив длинные строки:
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
|
public class StringUtilsTest {
private static String veryLargeString;
@BeforeClass
public static void setUpClass() {
veryLargeString = new BigInteger(16384, new Random()).toString();
}
@AfterClass
public static void tearDownClass() {
veryLargeString = "";
}
@Test
public void testToArrayLong() {
assertEquals("Should not be splitted", veryLargeString, StringUtils.toArray(veryLargeString, ':')[0]);
}
//Other class contents is skipped.
}
|
Обратите внимание, что функции, аннотированные @BeforeClass/@AfterClass традиционно называеются setUpClass и tearDownClass соответственно.
В примере перед запуском тестов генерируется длинная строка, которая освобождается после выполнения всех тестов. Очевидно, что все изменения, внесённые тестами в эту переменную, сохраняются. Следует помнить, что порядок тестов в обычных условиях не определён и может меняться между запусками, если другое поведение не указано явно.
Исходный код примера доступен на github