Как юнит-тестирование сделало вашу жизнь лучше?

Question

Хорошо, позвольте мне быть честным, я не написал более 10 тестов в своей жизни, вероятно.

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

Идея, что я могу псевдо-гарантия , что моя программа работает, вызывает чувство радости.

Конечно, я пропущу массу случаев, когда мне следовало бы пройти тестирование, но я научусь этому со временем.

Юнит-тестирование поможет мне лучше спать по ночам , что лучше для моего здоровья.

Мой код потерпит неудачу, но, по крайней мере, у меня будет лучшая идея, когда он будет .

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

Answer 1

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

При этом я могу указать на случай, когда модульные тесты сэкономили мне недели работы ...

Я работал над небольшим проектом (4-6 разработчиков) некоторое время назад, и после нескольких месяцев работы мы достигли состояния, близкого к завершению. В этот момент ответственные за продукт люди решили, что вместо того, чтобы хранить даты (и создавать отчеты с их использованием) в GMT, они хотели все в EST. Учитывая, что продукт был создан для обработки больших объемов данных / журналов и генерирования информации об этих данных на основе временных периодов, это было довольно серьезное изменение.

В течение следующих нескольких дней команда разработчиков пришла и изменила все, чтобы иметь дело с метками времени EST. Что бы заняло у нас недели, если бы у нас не было таких обширных автоматизированных тестов, мы заняли всего 3 дня, что позволило нам соблюсти агрессивный график. Мы смогли перейти к коду и начать изменять все, что нам нужно; модульные тесты дают нам смелость, зная, что система будет быстро жаловаться, если мы что-нибудь сломаем. До сегодняшнего дня я использую этот опыт в качестве примера того, как вы никогда не сможете по-настоящему понять преимущества автоматизированного тестирования, пока оно не спасет вас ... и это, безусловно, сделало это для моей команды.

Answer 2

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

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

Answer 3

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

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

Answer 4

Модульное тестирование не является серебряной пулей. Но у этого есть преимущества, и это очень приятно.

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

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

Answer 5

Я должен сказать, что я думаю, что улучшения в VS 2010, такие как Ctrl + Enter (я думаю, это было то, что было), которые могут позволить вам быстро заглушить интерфейс класса во время написания test (first) сделай это намного проще для меня.

Answer 6

Хорошие юнит-тесты, обеспечивающие достаточное покрытие, помогут вам лучше спать по ночам.

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

Answer 7

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

Я доберусь до конца, я уверен. Но на данный момент у меня плохое здоровье, я трачу 90% своей жизни на отладку: (

Answer 8

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

Это также вселяет в меня уверенность в беседе с другими разработчиками, утверждающими, что созданный мной API имеет ошибки.

Answer 9

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

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

(Это, конечно, верно только в том случае, если у вас есть тесты, которые не являются "просто" очень узкими тестами, единственными в своем роде, но я думаю, что это чаще, чем нет.)

Answer 10

Я проделал немалую работу в Java, и год в Ruby.

В Ruby мы использовали расширенное тестирование (TDD). Это было абсолютно необходимо. Вы можете записать почти полный мусор в файл Ruby, и если вы не попадете в эту конкретную строку кода, вы никогда не узнаете об этом, поэтому ваши тесты должны охватывать почти 100%.

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

Еще один интересный момент: в проекте Ruby у нас был рефакторинг, который занял у нас 2 дня реальной работы над кодом (разделив первичный класс модели на два класса) и 2 недели тестового ремонта.

В какой-то момент все эти тесты имеют цену, они все еще являются кодом, который вы должны поддерживать.

Тем не менее, я нахожу TDD забавным и хорошим способом начать работу, даже в Java, и я также хотел бы повторить, что У меня ВСЕГДА есть тестирование пути успеха как минимум (даже если это всего лишь быстрый метод main) практически в каждом классе я пишу.