Модульные тесты на рабочую кодовую базу с ограниченным временем: Как?
У меня есть несколько приложений для направляющих среднего размера, что я обычно продолжаю работать, и у только одного из них есть любые модульные тесты вообще. Но я видел свет, и я хочу изменить все это, кроме... У меня нет времени для входа и начинающий пишущий тестовый класс классом или чем-то как этот.
Как Вы начинаете писать модульные тесты на существующем - и работать - кодовая база с ограниченным временем? Например, так как какой-либо подход должен был бы быть поэтапным, как Вы закажете свою запись модульного теста? Запустите с поверхностных тестов, затем идите дальше к большему количеству покрытия или покройте всего несколько классов... и т.д.
Примечание: Я спрашиваю этот вопрос, думающий о направляющих, но действительно я интересуюсь тем, как он относится к любому языку.
Править: Отметьте, этим вопросом не является то же как это другое. Другой спрашивает, как трудно это и было результатом, стоящим того. Я спрашиваю о том, как добавить модульные тесты.
7 ответов
Вот как я обычно начинаю добавлять модульные тесты в проект, который не начинался таким образом: подождите, пока кто-нибудь сообщит об ошибке, затем напишите модульный тест, который воспроизводит ошибку. Затем исправьте unit test. Это не только запускает создание модульных тестов, но и теперь никто не может обвинить вас в регрессе данной ошибки.
Мой ответ не относится к Ruby on Rails. В следующий раз, когда вам нужно будет коснуться кодовой базы, чтобы исправить ошибку или добавить новую функцию, напишите тесты для частей кода, которых вы касаетесь. Если у вас есть пара минут, добавьте несколько связанных тестов. Если вы обнаружите, что вам нужно провести рефакторинг, напишите тесты для поддержки этого. Со временем вы увеличите охват тестами и обнаружите, что у вас всегда есть тесты для тех областей, в которых они вам нужны (потому что это те тесты, которые вы пишете).
Одна из проблем, с которыми я столкнулся, когда начал писать настоящие модульные тесты (с макетами и т. Д.), Заключалась в том, что мне пришлось вернуться и изменить код для поддержки внедрения фиктивных объектов в основном путем извлечения интерфейсов. Я считаю, что вам будет довольно сложно сделать это в существующей системе без какого-либо рефакторинга.
Увеличение покрытия кода - отличный способ познакомить новичка с базой кода.
Кроме того, я думаю, вам просто нужно найти время, волшебного решения нет!
В конечном итоге модульное тестирование должно ускорить получение (работающей!) Функциональности для пользователей.
Если это не удается, то не стоит тратить время.
С ограниченным временем? Сталкиваются с дедлайнами?
Забудьте о модульных тестах!
Ковбой кодирует 4 победы!
Взламывайте функции вместе, пока не стало слишком поздно и клиент не подал в суд на вашу компанию.
П.с. Для вашей безопасности - не не забудьте сообщить о ситуации в личку.
Странно, что лавина голосов противников еще не началась. Может быть, это не так уж и плохо, и запретить писать модульные тесты - вовсе не такое табу.
Я в похожей ситуации (при условии, что Ваше время действительно ограничено). Что я делаю - я не думаю о модульных тестах большую часть времени. Но в некоторых случаях - на самом деле проще сделать TDD, чем продолжать взламывать (эмм ... клейкая лента?: D) все вместе (обычно, когда тестируемый модуль имеет высокую сложность или его трудно протестировать вручную), тогда я просто переключаюсь и кодируйте нормально. Вкратце - я смогу понять, что написал месяц назад, и это не составит особого труда. Проблемы возникнут, когда проект перейдет в фазу обслуживания. Но это все же намного лучше, чем сказать клиенту, что вы работали над тестами и не получил ничего нового .
Когда вам нужно запустить модульное тестирование в существующем проекте - начните с собственного функционала. Создайте необходимую тестовую инфраструктуру (если позволяет время - и непрерывную интеграцию) и не забудьте обучить своих коллег модульному тестированию.
Худшее, что вы (или PM) можете сделать - заставить писать модульные тесты тому, кто не знает, как это делать. Это просто трата времени. Подавать пример. Постепенно.
В конце концов, это началось! ^ _ ^
Несколько лет назад у меня был очень похожий опыт, и я наткнулся на эту книгу:
Эффективная работа с устаревшим кодом Майкла К. Фезерса
Он имеет невероятно полный набор методов, позволяющих начать с существующей кодовой базы, не имеющей покрытия модульными тестами, и постепенно подвергнуть ее тестированию. Если бы я мог порекомендовать только одну книгу по TDD, то это была бы эта.
Надеюсь, это поможет ... удачи!
Тайлер