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

Question

Вы бы порекомендовали выполнить какую-либо группировку тестовых случаев в методах @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(...)

    ...
}

Любые отзывы будут оценены.

Answer 1

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

Во-первых, легче увидеть, какие случаи тестируются, если они разбиты на методы, а не искать комментарии, встроенные в код. Большинство IDE предоставят вам краткое описание методов, поэтому вместо того, чтобы сказать «я тестировал пограничный XYZ?» и затем ищите комментарий или ищите код, который устанавливает этот пограничный регистр, вы просто ищете метод с именем 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);
}

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

Answer 2

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

Answer 3

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

Answer 4

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

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

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

Такой подход рекомендуется в книге xUnit Test Patterns: рефакторинг кода теста Жерара Месароша.

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

1. Начальная настройка
2. Конструктор упражнений
3. Проверка по умолчанию
4. Упражнение для установки переменной контекста
5. Проверка установки переменной контекста
6. Разрушение

Answer 5

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

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

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

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