Используете ли вы модульное тестирование в своих профессиональных проектах?

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

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

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

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

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

Редактировать

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

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

Я заинтересован в этом, но не знаю, как начать делать это с крупными проектами, к которым я присоединяюсь на полпути ... Я не участвовал в настоящем новом запуске проекта с 1996 года!

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

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

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

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

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

С Java есть инструменты получше, так что вам действительно стоит начать писать тесты прямо сейчас! На самом деле отладка - отстой, тестирование скал.

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

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

Модульный тест (я думаю, здесь JUnit) и TDD - это то, что вам нужно, когда вы начинаете новый проект со свежим кодом (и вам понадобится больше, чем CI).

Но когда ваш новый проект должен изменить старую базу кода, полную тесно связанных классов с 5KLOC в каждом из них, тогда модульное тестирование затруднено, и в большинстве случаев временная шкала проекта не допускает рефакторинга (или перезаписи). Если вы собираетесь начать именно такой проект, я рекомендую вам прочитать «Работа с устаревшим кодом» для тестирования стратегий на старом коде.

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

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

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

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

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

Когда вы задаете вопрос на дискуссионном форуме, многие люди скажут, что модульное тестирование является «обязательным», но на самом деле, как показывают результаты опроса, модульное тестирование рассматривается. См. http://www.methodsandtools.com/dynpoll/oldpoll.php?UnitTest2 для получения дополнительных ссылок / материалов.

Я не могу себе представить работу над проектом без автоматизированного тестирования (Unit / Integration и т. д.)

На самом деле я часто говорю

"If this breaks, its not my fault"

при работе с кодом людей, не имеющим тестов.

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

Если стоило писать, стоит попробовать.