Поблочное тестирование в Java - что это? [закрытый]
Можете Вы объяснять в нескольких предложениях:
- Почему нам нужен он / почему они делают нашу жизнь легче?
- Как к модульному тесту [простой пример в Java]?
- Когда нам не нужны они / типы проектов, мы можем пропустить поблочное тестирование?
- полезные ссылки
6 ответов
Зачем они нам нужны / почему они делают нашу жизнь проще?
- Он позволяет проверить ожидаемое поведение тестируемого фрагмента кода, выступая в качестве контракта, которому он должен удовлетворять.
- Он также позволяет безопасно рефакторить код, не нарушая его функциональности (контракта).
- Он позволяет вам убедиться в том, что исправления ошибок остаются исправленными, внедряя юнит-тест после исправления ошибки.
- Он может служить способом написания развязанного кода (если вы планируете тестирование во время написания кода).
Как проводить юнит-тестирование [простой пример на Java] ?
Посмотрите сайт JUnit и JUnit cookbook для подробностей. В написании тестовых примеров JUnit нет ничего сложного. На самом деле придумать хорошие тестовые примеры, безусловно, сложнее, чем их реализовать.
Когда они нам не нужны / типы проектов, в которых можно обойтись без юнит-тестирования?
Не пытайтесь тестировать каждый метод в классе, а лучше сосредоточьтесь на тестировании функциональности класса. Например, для бобов вы не будете писать тесты для геттеров и сеттеров...
Ссылки
JUnit - модульное тестирование
EclEmma - инструмент покрытия тестами
текст ссылки - ссылка в Википедии на модульное тестирование
Вот каким должно быть ваше программирование:
- Определитесь с интерфейсом (не обязательно java-интерфейс, но как метод выглядит для всех
- Написать тест
- Запрограммировать реализацию
Одной из лучших книг о том, как и почему модульное тестирование на Java, является Pragmatic Unit Testing in Java with JUnit (Энди Хант & Дэйв Томас)
Возможно, стоит прочитать статью в Википедии о модульном тестировании , так как это ответит на большинство ваших вопросов относительно почему ]. На веб-сайте JUnit есть ресурсы для написания модульного теста Java, из которых Junit Cookbook , вероятно, будет вашей первой остановкой.
Лично я пишу модульные тесты для проверки контракта метода, то есть документации для конкретной функции. Таким образом, вы войдете в цикл увеличения тестового покрытия и улучшения документации. Однако вам следует избегать тестирования:
- чужой код, включая JDK
- Недетерминированный код, такой как java.util.Random
JUnit - не единственная среда модульного тестирования, доступная для Java, поэтому вам следует оценить другие фреймворки, такие как TestNG , прежде чем углубляться в них.
Помимо фреймворков «верхнего уровня», вы также найдете немало проектов, охватывающих определенные области, например:
Потому что это ваше доказательство того, что приложение действительно работает так, как задумано. Вы также намного легче обнаружите регрессионные ошибки. Тестирование станет проще, поскольку вам не придется вручную перебирать все возможные состояния приложения. И наконец, вы, скорее всего, обнаружите ошибки, о существовании которых даже не подозревали, хотя и тестировали код вручную.
Google для junit
Юнит-тесты должны быть написаны всегда, как уже было сказано, это ваше доказательство того, что приложение работает так, как задумано. Некоторые вещи невозможно или трудно протестировать, например, графический интерфейс пользователя. Это не значит, что GUI не следует тестировать, это лишь означает, что для этого следует использовать другие инструменты.
См. пункт 2.
То, что я бы написал, уже описано во многих ответах здесь, но я решил добавить вот это...
Лучшая статья о том, когда использовать/не использовать модульные тесты, которую я когда-либо читал, была на блоге Стива Сандерсона. Это отличная статья, в которой рассматриваются затраты/выгоды от использования модульных тестов в различных частях вашей базы кода (т.е. убедительный аргумент против 100% покрытия)
.