Желаемый: «Тест тестов»
Представьте себе, что есть некоторая дополнительная «проверка работоспособности», которая может быть выполнена после того, как тестовый класс завершит все свои тесты, которые будут указывать, было ли выполнение теста в целом выполнено успешно , Эта последняя проверка работоспособности может использовать некоторую обобщенную информацию о тестах. Просто в качестве грубого примера: подсчитывается количество вызовов к разделяемому методу, и если после завершения всех тестов это число не превышает некоторого минимального ожидаемого порога, становится ясно, что что-то не так, даже если все отдельные тесты пройдены.
То, что я описал, возможно, относится к «серой области» лучших практик, потому что, хотя оно нарушает doctrine модульных тестов atomi c, окончательная проверка работоспособности на самом деле не является тестирование тестируемого класса; скорее это проверка того, что выполнение теста в целом было успешным: так называемый «тест тестов». Это дополнительная логика c в отношении самих тестов.
Это решение кажется плохим
Один из способов выполнить sh этот «тест тестов» - поместить проверку работоспособности в состояние c @AfterClass
метод. Если проверка не удалась, можно вызвать Assert.fail()
, что на самом деле работает (удивительно, поскольку я предполагал, что ее можно вызывать только из методов, помеченных @Test
, которые по своей природе должны быть методами экземпляра, а не stati c):
public class MyTest {
[...]
@AfterClass
public static void testSufficientCount() {
if (MyTest.counterVariable < MIN_COUNT) {
Assert.fail("This fail call actually works. Wow.");
}
}
}
Существует множество причин, по которым это решение является клуджем:
- Предположим, что всего
N
тестов (где "тест" - это метод экземпляра, аннотированный * * тысяча двадцать-одиной). Когда Assert.fail()
является , а не , вызванным в @AfterClass
, в IDE, как и ожидалось, сообщается общее количество тестов N
. Однако, когда Assert.fail()
вызывается в @AfterClass
, IDE сообщает всего N + 1
тестов (дополнительным является метод stati c @AfterClass
). Дополнительный метод stati c был , а не с аннотацией @Test
, поэтому его не следует считать тестом. Кроме того, общее количество тестов не должно зависеть от того, пройдены некоторые тесты или нет. - Метод
@AfterClass
по определению является stati c. Таким образом, доступны только участники c. Это представляет проблему для моей конкретной ситуации c; Я оставлю это утверждение без подробностей, потому что объяснение выходит за рамки вопроса, но в целом было бы наиболее желательно, если бы использовались только члены экземпляра. - [Другие причины тоже ...]
Есть ли лучший путь?
Есть ли способ реализовать этот "тест испытаний", который считается хорошей и распространенной практикой? Поддерживает ли JUnit 4 добавление некоторого вида logi c, чтобы гарантировать, что группа модульных тестов внутри класса выполняется должным образом (в некотором роде, если они этого не сделали)? Есть ли название для этой вещи, которую я назвал «тест испытаний»?