jUnit fail () соглашения

Question

Мне интересно, по соглашению, если тест не пройден, уместно ли:

• Скажите, почему это не удалось (бизнес-логика)
• Скажите, почему сообщение увидено (исключение должно было быть сгенерировано, а оно нет)

Например,

fail("Accessed the element which does not exist");

или

fail("ArrayIndexOutOfBoundException was expected but something bad happened");

Какой из них, как правило, является предпочтительным / принятым?

Answer 1

Во-первых, если вы ожидаете, что тестируемый API выдаст исключение, вместо try-catch с fail() ...

@Test
public void testMe() {
   try {
      api.testThis();
      fail("should not reach here");
   }
   catch(MyException e) {}
}

... вы должны сделать это: -

@Test(expected=MyException.class)
public void testMe() {
   api.testThis();
}

Тем не менее, я редко использую fail().Если мне нужно выполнить определенную проверку и условие не выполнено, я, скорее всего, буду использовать утверждения, чем использовать fail() ... например: -

... вместо ...

@Test
public void testMe() {
   boolean bool = api.testThis();
   if (!bool) {
      fail("should be true because bla bla bla");
   }
}

... сделать это: -

@Test
public void testMe() {
   boolean bool = api.testThis();
   assertTrue("bla bla bla",bool);
}

Однако, если вам действительно нужно использовать fail(), будьте многословны и объясните, почему он терпит неудачу, а не "не должен достигать здесь" или "должен потерпеть неудачуздесь ", потому что это не помогает людям, которые читают тестовые случаи.

Конечно, это всего лишь простые примеры .... но я думаю, что я понял свои мысли.:)

Answer 2

Учитывая, что это тестовый код, и он не должен входить в финальную сборку, я бы сказал, что чем больше многословно, тем лучше. Таким образом, я бы остановился на первом - гораздо яснее, какова основная причина проблемы, и ее легче исправить.

Я бы избегал второго при любых обстоятельствах, потому что он не очень полезен для тестировщика, и если он каким-то образом превращает его в финальную сборку, он даже более загадочный, чем первый для конечного пользователя - он просто не поможет для тестировщиков или пользователей.

Еще один вариант, который я рассмотрю, - это не указание на возникновение исключения, а подробное описание фактического исключения - именно поэтому были изобретены трассировки стека. Это дало бы больше деталей, чем любой из перечисленных методов.

Answer 3

Если бы было соглашением об этом, я бы проигнорировал его.Вы должны сказать, что лучше всего донести до тех, кто видит это сообщение, природу проблемы так, чтобы ее можно было решить как можно проще.Слишком часто придерживаться соглашения не удается в этом отношении.