Основные jUnit Вопросы

Истинное количество тестов, конечно, бесконечно. Это непрактично. Вы должны выбрать допустимые репрезентативные кейсы. Похоже, вы это сделали. Молодец.

1) Я действительно считаю хорошей идеей ограничить количество утверждений, которые вы делаете в каждом тесте. JUnit сообщает только о первом сбое в тесте, поэтому, если у вас есть несколько утверждений, некоторые проблемы могут быть замаскированы. Более полезно иметь возможность видеть все, что прошло, и все, что не удалось. Если у вас есть 10 assertEquals в одном тесте, а первый не прошел, тогда вы просто не знаете, что произошло бы с другими 9. Это были бы хорошие точки данных, которые нужно иметь при отладке.

2) Да, вы должны включить тесты для всех ваших входных данных.

3) Необходимо тестировать не только вводимые пользователем данные. Вы захотите написать тесты для любых общедоступных методов, которые могут дать сбой. В JUnit FAQ есть несколько хороших рекомендаций для этого, особенно в отношении геттеров и сеттеров.

4) Думаю, у вас это довольно хорошо описано. (По крайней мере, я не могу думать ни о чем другом, но вижу № 5).

5) Раздайте его некоторым пользователям для тестирования. Они всегда находят образцы данных, которые я никогда не думаю о тестировании. :)

Я просто хочу добавить, что с модульным тестированием вы можете получить еще больше, если сначала подумайте о возможных случаях, а затем внедрите в тестируемый development, потому что это поможет вам сосредоточиться на текущем случае, и это позволит вам создать самую простую возможную реализацию в режиме DRY. Вы также можете использовать какой-нибудь инструмент для покрытия тестов, например в Eclipse EclEmma, ​​который действительно прост в использовании и покажет вам, выполнили ли тесты весь ваш код, что может помочь вам определить, когда этого достаточно (хотя это не доказательство, а просто показатель). Как правило, когда дело доходит до модульного тестирования, меня очень вдохновила книга Кента Бекса «Разработка через тестирование на примерах», я настоятельно рекомендую ее.

Модульное тестирование - это здорово (в проекте 200 KLOC, над которым я работаю, у меня столько же кода модульного теста, сколько и обычного кода), но (при условии правильного модульного теста):

• успешно пройденный модульный тест выполняет not гарантирует, что ваш код работает

Подумайте об этом так:

• неудачный модульный тест доказывает, что ваш код неисправен

Это действительно важно понимать.

В дополнение к этому:

• обычно невозможно протестировать все возможные входные данные

А затем, когда вы выполняете рефакторинг:

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

Но:

• если один из ваших модульных тестов терпит неудачу, вы знаете, что вы ввели регрессию

Это действительно фундаментально и должно быть модульное тестирование 101.

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

Однако вместо ручного написания теста для каждого отдельного «недопустимого сценария» вы можете взглянуть на теории JUnit 4.4 (см. примечания к выпуску JUnit 4.4 и этот блог post ) или средство запуска тестов JUnit Parameterized .

Параметризованные тесты и теории идеально подходят для таких «расчетных» методов, как этот. Кроме того, чтобы все было организовано, я мог бы сделать два тестовых класса: один для «хороших» входных данных, а второй - для «плохих».

2) Вам нужно включить только те тестовые примеры, которые, по вашему мнению, наиболее вероятно обнаружат какие-либо ошибки в вашем коде, а не все возможные комбинации всех входных данных (что было бы невозможно, как WizardOfOdds указывает в своих комментариях). Три набора, которые вы предложили, хороши, но я, вероятно, не стал бы тестировать больше, чем эти три. Однако использование теорий или параметризованных тестов позволит вам добавить еще больше сценариев.

3) Написание модульных тестов дает множество преимуществ, не только то, о котором вы упомянули. Некоторые другие преимущества включают:

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

5) Похоже, вы хорошо поработали, придумав возможные сценарии тестирования. Думаю, у тебя есть все важные.