Подтвердить что ты не робот

Проверить значение по умолчанию и сеттер в одном тестовом случае или в отдельных тестовых случаях

Вы рекомендуете делать какие-либо группировки тестовых случаев в методах @Test или использовать один метод @Test для каждого тестового сценария? Например, допустим, что существуют разные способы установки контекста в приложении.

Является ли следующая идея приемлемой?

@Test
public void testContextSetting() {
    // Test default setting
    assert(...)

    // Test setting a context variable
    assert(...)

    ...
}

Или, скорее всего, предпочтете сделать это так, чтобы каждый метод был максимально атомным:

@Test
public void textDefaultSetting() {
    // Test default setting
    assert(...)
}

@Test
public void testSettingContextVar() {
    // Test setting a context variable
    assert(...)

    ...
}

Любая обратная связь будет оценена.

4b9b3361

ОТВЕТЫ

Ответ 1

Я предпочитаю иметь один тестовый пример для каждого метода.

Сначала легче увидеть, какие случаи проверяются, если они разделены на методы, а не искать комментарии, встроенные в код. Большинство IDE дадут вам краткое описание методов, поэтому вместо того, чтобы сказать "я тестировал edgecase XYZ?" а затем для поиска комментария или поиска кода, который устанавливает эту edgecase, вы просто ищете метод с именем setupContextEdgeCaseXYZ().

Вторая причина заключается в том, что если у вас есть несколько случаев вместе, вы можете потерпеть неудачу, а затем другие никогда не выполняются.

 testDefaultCase()
 testInvalidInput()
 testEdgeCase1()
 testEdgeCase2()

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

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

@Test
public void testMyMethod() {
  //test default
  String test = Foo.bar(null);
  assertEquals("foo", test);

  //test case 1
  Foo.bar(aValue);
  //Oops forgot to set value above, this passes regardless of 
  //what the above call does
  assertEquals("foo", test);
}

Разбирая случаи, вы можете избежать ошибок, как указано выше, поскольку это превратилось бы в компиляцию или предупреждение.

Ответ 2

Лучшей практикой является наличие одного тестового примера для каждого метода. Имя метода описывает тест, который вы выполняете. Легче отлаживать, когда ваш тест терпит неудачу, когда это всего лишь одно утверждение.

Ответ 3

Divide et impera:) так разбивается на несколько мелких случаев... легче исправить в случае ошибок.

Ответ 4

Вы вводите в заблуждение тест с утверждением. Ваш тестовый метод с несколькими assert проверяет несколько вещей: значение по умолчанию и задание переменной контекста. Но метод тестирования, который проверяет одну вещь, может также иметь несколько assert s.

Хороший шаблон для использования - для каждого тестового случая есть четыре фазы:

  • Настройка: где вы создаете объекты, необходимые для выполнения теста, и при необходимости изменяете эти объекты, чтобы поместить их в требуемые начальные состояния.
  • Упражнение: где вы выполняете операцию, которую вы тестируете. Это будет один вызов метода или вызов конструктора.
  • Проверить: где вы проверяете, что тестируемые объекты находятся в правильном состоянии (состояниях), и проверьте значение, возвращаемое методом, вызванным на этапе выполнения, если оно вернуло значение. Здесь вы размещаете свои assert s. Если вы используете этот шаблон, нет ничего плохого в размещении нескольких assert в фазе проверки.
  • Teardown: где вы уничтожаете или закрываете объекты, которые вы использовали для выполнения теста.

Это подход, рекомендованный в книге xUnit Test Patterns: Рефакторинг тестового кода Джерардом Мезаросом.

Сравните этот шаблон с тем, что у вас есть в первом примере, в котором, похоже, вы это сделаете:

  • Начальная настройка
  • Конструктор упражнений
  • Проверить значение по умолчанию
  • Упражнение для установки переменной контекста
  • Проверить настройку переменной контекста
  • Teardown

Ответ 5

Eclipse генерирует unit test за метод, который, по-видимому, является разумным подходом. Если тестируемый метод слишком сложный, чтобы протестировать его с использованием одного тестового метода, вы можете рассмотреть вопрос о его повторном использовании.

Но гораздо более лучший подход - использовать TDD и написать тесты, которые будут управлять остальной частью дизайна и реализации.

Лично я предпочитаю иметь один тест на один метод вместе с Java Code Coverage для Eclipse http://www.eclemma.org.

Инструмент скажет вам, что вы на самом деле тестируете.