Ксакеп, aNNiMON, у меня в универе тестированию не учили. Писать статью о полезности тестирования по-моему бесполезно. Я читал о тестировании и статьи на хабре, и руководства по JUnit и прочие руководства, но проникся только когда начал применять тесты на реальном проекте, над которым работал с февраля до конца прошлой недели. Ну как начал - пришлось, месяц плевался, но потом увидел, что это помогает отловить ошибки при реализации новых фич, который ломали уже написанный функционал, и втянулся. Лучше потратить полчаса на написание теста, чем перед git push или svn commit вспоминать, в каком месте правки могут сломать старый код и проверять корректность вручную. А если закоммитить, понадеявшись на авось, то потом может и от тимлида прилететь вежливая просьба немедленно пофиксить =)
Naik, тест считает некорректным сообщение, если у него префикс с одними пробелами: " ". А при реализации метода проверки сообщения я мог бы запросто забыть вызвать trim() и без тестирования баг мог всплыть когда-нибудь потом случайно. Тесты помогут быстро обнаружить факт регрессии в коде, если реализация валидации в будущем усложнится и логика станет не такой очевидной. А при изменении кода даже самим автором какие-то ошибки в будущем могут прокрасться, и заметить их сразу будет тяжело, возможно, их даже и не заметят до самого релиза.
Naik, в php с этим попроще: сохранил и всё. Я так в ruby иногда тоже делаю.
а хорошие тесты не должны модифицировать тот код, который они проверяютПри условии, что система спроектирована грамотно и замОчить объекты не составляет никакого труда. Нас, к сожалению, в универе так и не обучили юнит-тестированию, а сам я пытался, но практической ценности из этого не извлёк. Так что тесты не пишу, хотя это нужная штука. Юнит тесты имеет смысл писать, когда разрабатывается какая-либо библиотека или фреймворк. Когда пишешь приложение, которое предназначено для конечного пользователя, то пишутся функциональные тесты, которые будут проверять взаимодействие компонентов вместе. Польза состоит в том, что при внесении изменений в код, они могут дать гарантию того, что нигде ничего не сломалось. Бытует мнение, что функциональные тесты писать проще, чем юнит тесты. Я не знаю, насколько это правда, но по своему опыту могу сказать, что функциональные всё-таки гораздо сложнее. В веб разработке при написании функциональных тестов обычно используется selenium webdriver или его альтернативы. Этот тот ещё гемморой скажу я вам, особенно, когда сталкиваешься с этим впервые и ни разу не слышал о pageobject, не знаешь всех особенностей тестирования с помощью вебдрайвера. Уходит очень много времени. Конечно и на юнит тесты тоже уходит достаточно времени, но там хотя бы ты точно можешь быть уверен в результате. С вебдрайвером же не всегда ясно, пройдёт ли тест, который ты только что написал, в следующий раз или нет. Конечно такое случается не всегда, но случается. И это очень не приятно, потому что выявить причину проблемы не так то и просто.
Отличная статья. У нас в вузе с первого семестра приучают к unit-тестированию.
Получается мы просто предусматриваем разные ошибки, а это уже исключает ошибку в коде. Т.е. если мы в тесте проверяем поля сообщения, то в самом коде нет проверки что ли?
Тесты для слабаков!
А ведь классная статья! В свободное время нужно будет обязательно помедитировать над ней.
Фух, осилил. Статья является неплохим введением в тестирование mock-объектов, но всё же не побуждает писать тесты. Неплохо было бы ввести сначала в само тестирование и его полезность. Нас, к сожалению, в универе так и не обучили юнит-тестированию, а сам я пытался, но практической ценности из этого не извлёк. Так что тесты не пишу, хотя это нужная штука.
Я не смог полноценно понять. Даже не дочитал, тяжело воспринимается.  К записиJavaКатегории
|
Мы в соцсетях
|
Freddy 
საქარტველოს გაუმარჯოს
