В fail()библиотеке JUnit4 есть метод. Мне это нравится, но испытываю нехваткуpass() метода, которого нет в библиотеке. Почему это так?
Я обнаружил, что могу использовать assertTrue(true)вместо этого, но все равно выглядит нелогично.
@Test
public void testSetterForeignWord(){
try {
card.setForeignWord("");
fail();
} catch (IncorrectArgumentForSetter ex){
}
// assertTrue(true);
}
passметода.
Ответы:
Пока тест не генерирует исключение, он проходит, если в вашей @Testаннотации не указано ожидаемое исключение. Я полагаю, что a pass()может вызвать специальное исключение, которое JUnit всегда интерпретирует как прохождение, чтобы сократить тест, но это будет противоречить обычному дизайну тестов (т.е. предположить успех и только потерпеть неудачу, если утверждение не выполняется) и, если люди получили идея, которую было бы предпочтительнее использовать pass(), значительно замедлила бы прохождение большого набора тестов (из-за накладных расходов на создание исключений). Неудачные тесты не должны быть нормой, поэтому нет ничего страшного, если у них есть такие накладные расходы.
Обратите внимание, что ваш пример можно переписать так:
@Test(expected=IncorrectArgumentForSetter.class)
public void testSetterForeignWord("") throws Exception {
card.setForeignWord("");
}
Кроме того, вы должны отдавать предпочтение использованию стандартных исключений Java. Вы IncorrectArgumentForSetterдолжны , вероятно , быть IllegalArgumentException.
pass()метод не может просто ничего не делать, иначе тест может не сработать после его вызова. Я удалил это предложение.
Я думаю, что на этот вопрос нужен обновленный ответ, поскольку большинство ответов здесь довольно устарели.
Во-первых, на вопрос OP:
Я думаю, что довольно хорошо принято, что введение концепции «ожидаемого исключения» в JUnit было плохим ходом, поскольку это исключение могло возникнуть где угодно, и оно пройдет проверку. Это работает, если вы генерируете (и утверждаете) очень специфичные для домена исключения, но я выбрасываю только такие исключения, когда я работаю над кодом, который должен быть абсолютно безупречным, - большинство APIS просто выбрасывает встроенные исключения, такие как IllegalArgumentExceptionили IllegalStateException. Если два ваших вызова могут потенциально вызвать эти исключения, тогда @ExpectedExceptionаннотация будет зеленой полосой для вашего теста, даже если это неправильная строка, которая вызывает исключение!
Для этой ситуации я написал класс, который, я уверен, многие здесь написали, это assertThrowsметод:
public class Exceptions {
private Exceptions(){}
public static void assertThrows(Class<? extends Exception> expectedException, Runnable actionThatShouldThrow){
try{
actionThatShouldThrow.run();
fail("expected action to throw " + expectedException.getSimpleName() + " but it did not.");
}
catch(Exception e){
if ( ! expectedException.isInstance(e)) {
throw e;
}
}
}
}
этот метод просто возвращает, если возникает исключение, что позволяет вам выполнять дальнейшие утверждения / проверки в вашем тесте.
с синтаксисом java 8 ваш тест выглядит действительно красиво. Ниже приведен один из самых простых тестов нашей модели, в котором используется этот метод:
@Test
public void when_input_lower_bound_is_greater_than_upper_bound_axis_should_throw_illegal_arg() {
//setup
AxisRange range = new AxisRange(0,100);
//act
Runnable act = () -> range.setLowerBound(200);
//assert
assertThrows(IllegalArgumentException.class, act);
}
эти тесты немного неудобны, потому что шаг «действие» на самом деле не выполняет никаких действий, но я думаю, что смысл все еще довольно ясен.
в maven также есть крошечная библиотека, называемая catch-exception, которая использует синтаксис в стиле mockito для проверки того, что исключения генерируются. Выглядит симпатично, но я не фанат динамических прокси. Тем не менее, синтаксис настолько хорош, что остается заманчивым:
// given: an empty list
List myList = new ArrayList();
// when: we try to get the first element of the list
// then: catch the exception if any is thrown
catchException(myList).get(1);
// then: we expect an IndexOutOfBoundsException
assert caughtException() instanceof IndexOutOfBoundsException;
Наконец, для ситуации, с которой я столкнулся, чтобы добраться до этой темы, есть способ игнорировать тесты, если выполняется какое-то условие.
Прямо сейчас я работаю над вызовом некоторых DLL через библиотеку загрузки собственной библиотеки Java под названием JNA, но наш сервер сборки находится в ubuntu. Мне нравится управлять такого рода разработками с помощью тестов JUnit - даже если они на данный момент далеки от «единиц» -. Что я хочу сделать, так это запустить тест, если я нахожусь на локальной машине, но игнорировать тест, если мы на ubuntu. В JUnit 4 есть для этого положение, которое называется Assume:
@Test
public void when_asking_JNA_to_load_a_dll() throws URISyntaxException {
//this line will cause the test to be branded as "ignored" when "isCircleCI"
//(the machine running ubuntu is running this test) is true.
Assume.assumeFalse(BootstrappingUtilities.isCircleCI());
//an ignored test will typically result in some qualifier being put on the results,
//but will also not typically prevent a green-ton most platforms.
//setup
URL url = DLLTestFixture.class.getResource("USERDLL.dll");
String path = url.toURI().getPath();
path = path.substring(0, path.lastIndexOf("/"));
//act
NativeLibrary.addSearchPath("USERDLL", path);
Object dll = Native.loadLibrary("USERDLL", NativeCallbacks.EmptyInterface.class);
//assert
assertThat(dll).isNotNull();
}
Я также искал passметод для JUnit, чтобы я мог сократить некоторые тесты, которые не были применимы в некоторых сценариях (есть интеграционные тесты, а не чистые модульные тесты). Так что жаль, что его там нет.
К счастью, есть способ условно игнорировать тест, который в моем случае подходит даже лучше, используя assumeTrueметод:
Assume.assumeTrue (isTestApplicable);
Таким образом, здесь тест будет выполняться, только если isTestApplicable истинно, иначе тест будет проигнорирован.
В методе передачи нет необходимости, потому что, когда из тестового кода не выбрасывается AssertionFailedException, модульный тестовый пример будет пройден.
Метод fail () фактически генерирует исключение AssertionFailedException, чтобы не выполнить testCase, если в этот момент доходит управление.
Я думаю, что этот вопрос - результат небольшого непонимания процесса выполнения теста. В JUnit (и других инструментах тестирования) результаты подсчитываются для каждого метода, а не для каждого вызова assert. Нет счетчика, который отслеживает, сколько прошло / не assertXудалось выполнить.
JUnit выполняет каждый тестовый метод отдельно. Если метод завершился успешно, значит тест зарегистрирован как «пройден». Если возникает исключение, то тест регистрируется как «не пройденный». В последнем случае возможны два подслучая: 1) исключение утверждения JUnit, 2) исключения любого другого типа. В первом случае статус будет «сбой», а во втором - «ошибка».
В Assertклассе доступно множество сокращенных методов для выдачи исключений утверждений. Другими словами, Assertэто уровень абстракции над исключениями JUnit.
Например, это исходный код assertEqualsна GitHub :
/**
* Asserts that two Strings are equal.
*/
static public void assertEquals(String message, String expected, String actual) {
if (expected == null && actual == null) {
return;
}
if (expected != null && expected.equals(actual)) {
return;
}
String cleanMessage = message == null ? "" : message;
throw new ComparisonFailure(cleanMessage, expected, actual);
}
Как видите, в случае равенства ничего не происходит, иначе будет выброшено исключение.
Так:
assertEqual("Oh!", "Some string", "Another string!");
просто генерирует ComparisonFailureисключение, которое будет перехвачено JUnit, и
assertEqual("Oh?", "Same string", "Same string");
ничего не делает.
В общем, что-то вроде pass()бы не имело никакого смысла, потому что ничего не делало.