Я просто обнаружил при создании некоторых тестов CRUD, что Вы не можете установить данные в одном тесте и иметь его чтение в другом тесте (данные задержаны к его инициализации между каждым тестом).
Все, что я пытаюсь сделать, (C), повторно съел объект с одним тестом и (R) ead это со следующим. JUnit имеет способ сделать это, или он идеологически кодируется таким образом, что тестам не позволяют зависеть друг от друга?
Что ж, для модульных тестов вашей целью должно быть тестирование наименьшего изолированного фрагмента кода, обычно метод за методом.
Итак, testCreate ()
- это тестовый пример, а testRead ()
- другой. Однако ничто не мешает вам создать testCreateAndRead ()
для совместной проверки двух функций. Но тогда, если тест не пройден, на каком блоке кода тест не проходит? Вы не знаете. Такого рода тесты больше похожи на интеграционные, к которым нужно относиться по-другому.
Если вы действительно хотите это сделать, вы можете создать переменную статического класса для хранения объекта, созданного testCreate ()
, а затем использовать его в testRead ()
.
Поскольку я понятия не имею, о какой версии Джунита вы говорите, я просто взял старую версию Джунита 3.8:
Совершенно уродливо, но работает:
public class Test extends TestCase{
static String stuff;
public void testCreate(){
stuff = "abc";
}
public void testRead(){
assertEquals(stuff, "abc");
}
}
Сколько времени занимает обработка этих тестов? Если не много, то зачем беспокоиться. Конечно, вы создадите какой-то объект без необходимости, но сколько это вам стоит?
@Test
void testCreateObject() {
Object obj = unit.createObject();
}
@Test
void testReadObject() {
Object obj = null;
try {
obj = unit.createObject(); // this duplicates tests aleady done
} catch (Exception cause) {
assumeNoException(cause);
}
unit.readObject(obj);
}
JUnit продвигает независимые тесты. Один из вариантов - объединить два логических теста в один метод @Test.
TestNG был частично создан, чтобы разрешить такие зависимости между тестами. Он применяет локальные объявления зависимостей тестов - он запускает тесты в допустимом порядке и не запускает тесты, которые зависят от неудачного теста. См. Примеры http://testng.org/doc/documentation-main.html#dependent-methods .