С чего начать использование модульного тестирования?

Question

С чего начать использование модульного тестирования?
У меня есть некоторые сомнения относительно того, с чего начать использовать модульное тестирование.
Я делаю юнит-тестирование с Junit в RAD. И я делаю это после того, как весь код готов к развертыванию или может быть после развертывания. Я запутался, почему мы проводим модульное тестирование после того, как код почти готов к развертыванию.
Мой вопрос, когда мы должны начать модульное тестирование?

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

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

Теперь вот мой вопрос ...
Я делаю правильное юнит-тестирование? Поскольку один метод модульного тестирования включает в себя весь поток кода и дает результат ...

Answer 1

Лучшее время для начала юнит-тестирования, если вы еще этого не сделали, сейчас. Наиболее эффективным использованием модульных тестов является разработка через тестирование (TDD), в которой вы пишете тесты для каждого метода по мере его реализации (пишите тест, который не проходит, а затем реализует метод, чтобы он прошел). Однако еще не поздно добавить тесты позже. Тесты JUnit подтверждают некоторые предположения о коде, который может измениться позже. Если предположение изменится, тест прекратится, и вы сможете уберечь себя от некоторых ошибок, которые действительно трудно обнаружить.

Я не знаю возможности создания отчетов, но вы можете добавить задачу JUnit ANT, которая будет выводить результаты теста на консоль сборки (или в журнал, если вывод муравья захвачен).

Тесты вашей базы данных звучат как небольшие интеграционные тесты, а не модульные тесты. Это хорошо, но если тесты слишком медленные, вы можете подумать об использовании фиктивных объектов (с помощью инфраструктуры, такой как JMock или EasyMock), чтобы заменить реальные соединения с БД поддельными. Это изолирует логику метода от состояния и поведения базы данных и позволяет запускать тесты, не беспокоясь о том, работает ли БД и содержит ли она тестовые данные.

Полезные ссылки:

http://en.wikipedia.org/wiki/Test-driven_development

http://www.jmock.org/

http://easymock.org/

http://ideoplex.com/id/25/ant-and-junit

http://ant.apache.org/manual/Tasks/junit.html

http://misko.hevery.com/code-reviewers-guide/ (Руководство по написанию кода, проверяемого модулем)

[Редактировать - в ответ на комментарий]: Относительно того, что вы сделали, это правильное юнит-тестирование, технически ответ «нет». Как я уже сказал, это скорее интеграционный тест, который хорош, но он делает слишком много и имеет слишком много зависимостей, чтобы считаться настоящим модульным тестом. В идеале, модульный тест будет проверять логику в методе, а не в зависимости. Упомянутое выше руководство по написанию тестируемого кода (а также связанный с ним блог Misko Hevery) дает несколько полезных советов о том, как писать код со швами для вставки макетов зависимостей. Майкл Фезерс углубляется в эту тему в своей превосходной книге Эффективная работа с устаревшим кодом .

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

Answer 2

Вы должны действительно написать свои тесты как можно раньше, в идеале, прежде чем писать свою реализацию.

Это книга, которую я нашел полезной по этому вопросу, и которую стоит прочитать ... http://www.amazon.com/Test-Driven-Development-Addison-Wesley-Signature/dp/0321146530

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

Модульные тесты должны проверять только ту «часть» кода, которая вас интересует. То есть вызов вашего метода должен просто проверить этот метод. Не следует беспокоиться о связности базы данных и доступе к данным. Вы можете добиться этого, используя объекты «Mock», чтобы временно заменить ваши зависимости.

См .: http://msdn.microsoft.com/en-us/library/aa730844.aspx

Хотя этот документ от Microsoft и вы используете Java, применяются те же принципы.

Надеюсь, это поможет.

Answer 3

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

Модульные тесты, как следует из их названия, используются для проверки «единицы» работы. Вы не должны иметь ни одного теста, выполняющего слишком много. Также модульным тестом должно быть тестирование функциональности из одного класса.

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

Answer 4

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

Answer 5

Мой вопрос, когда мы должны начать юнит-тестирование?

Не "после того, как весь код готов к развертыванию". Не «после развертывания». Это слишком поздно Как и многие другие советуют, лучшее время (как раз) до написания кода, в стиле TDD.

Теперь вот мой вопрос ... я делаю правильное юнит-тестирование? С одного Метод модульного тестирования включает в себя весь код текут и дают результат ...

Вы не проводите «правильное» модульное тестирование. unit , который вы тестируете, является методом класса, но он также тестирует соединение с базой данных, что обычно делает тесты слишком медленными для выполнения так часто, как нам хотелось бы, и ломкими. Это не значит, что ваши тесты бесполезны - они вполне могут быть полезны - они просто не являются хорошими юнит-тестами.

Предположим, в вашей базе данных были правильные данные, и ваша программа имела к ней прочную связь. Какую ценность ваш метод получит из базы данных в ходе теста? Просто поместите это значение непосредственно, чтобы проверить функциональность этого метода. Так что работает даже без базы данных. Что это такое? Ваш метод не работает таким образом? Может быть, это слишком много. Может быть, это (а) получение данных из базы данных и (б) сделать расчет. Может быть, вы действительно хотите проверить только (б) (я думаю, что вы делаете). Разделите (a) и (b) на части, чтобы получить себе шов (согласно терминологии Майкла Фезерса), в который вы можете ввести данные теста из метода тестирования. Что у тебя сейчас? Лучший дизайн. Каждый метод делает только одну вещь. Слабее сцепление. И вы попали туда, потому что ваши тесты привели вас туда. То, что является разработкой, управляемой тестами.

Answer 6

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

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

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

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

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

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

Answer 7

Выполнение сертифицированной разработки требует от вас следовать определенной модели развития. Наиболее используемая модель - это модель V, которая, проще говоря, определяет требования, спецификации, подспецификации (например, спецификации для компонентов, модулей или блоков) и т. Д. Сверху вниз в левой ветви V. Вы, наконец, достигли нижней части V когда спецификации определяют атомную единицу, которая не может быть разумно разбита на более мелкие части.

В правой части V-модели вы выполняете проверки на соответствие модуля develloped его спецификациям и / или требованиям. Обычно используется для создания теста параллельно или перед внедрением проверяемого оборудования (тестируемого устройства). Таким образом вы гарантируете, что любой модуль вписывается в его структуру с самого начала и даже при некоторой переделке.

Как уже говорили другие, старайтесь, чтобы тесты были как можно проще, используя макеты и т. Д., Когда это возможно. Вам также следует автоматизировать свои тесты, по крайней мере те, которые относятся к модулям, расположенным в нижней части V, так как эти тесты обычно выполняются гораздо чаще, чем в верхней части.

Делать правильные отчеты намного проще, когда ваши тесты имеют четко определенный вывод. У нас обычно есть структура перечисления (пройдено, не удалось, ошибка), номер статуса и текст сообщения.