Исследование через функциональное тестирование

Предисловие

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

Зачем планировать

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

Планирование технических задач

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

1. Исследование кода, которые гипотетически необходимо подвергнуть изменению.
   Данный подход можно применить если вы очень хорошо ориентируетесь в реализации, и практически со стопроцентной уверенностью можете сказать, какие части системы будут подвержены изменениям
2. Исследование логов системы.
   В случае если вы не уверены в своих заниях о реализации системы и её поведении, можно обратиться к логам. Предварительно можно попросить пользователя ввести входные данные и посмотреть, какой след в логах оставила система. После этого, вы можете с уверенностью сказать, какая часть реализации выполняет тот или иной бизнес алгоритм и оценить трудозатраты по реализации новой логики
3. Написать тесты
   Пользователя, к которому можно обратиться для воспроизведения поведения системы нет. А если и есть, то обращаться каждый раз — дело неблагодарное, да и самим не хочется все повторять вручную. Почему бы не написать автоматизированный тест, перед реализацией алгоритма?
   
   Да, именно об ATDD (Acceptance Test Driven Development) и функциональных тестах идет речь.
   Об этом типе тестов необходимо заботиться сразу после старта проекта. Фрэймворк для написания и выполнения таких тестов должен эволюционировать вместе с проектом. Он должен быть легко расширяем и масштабируем. Кроме того, прогон таких тестов должен поддерживаться на Continuous Integration.
   Если у вас есть тест воспроизводящий текущее поведение системы и вы знаете каков должен быть результат, то половина дела уже сделана. Осталось оценить ту самую дельту, которую необходимо реализовать чтобы: а) не попадали существующие тесты, и б) новый тест с новыми ожидаемыми выходными данными тоже проходил.
   
   Возникает вполне себе политический вопрос. Неужели необходимо писать такие тесты перед планированием задачи? Ответом может служить тот факт, насколько быстро ваш functional testing framework позволяет писать такого рода тесты. Если это вопрос пару часов времени то, ответ да, лучше написать, если нет, то стоит задуматься о Technical Dept и в ближайшее время исправить ситуацию.
   
   Если вы используете итерационную методику разаработки, позаботьтесь о том, чтобы перед очередной итерацией User Story была достаточно ясна с точки зрения требований. Требования могли бы легко преобразованы в Acceptance Tests, specification by example (SBE) вам в помощь. SBE между прочим хорошо интегрируются в такие Testing Tools как Fitnees, BDD реализации такие как Spock, Easyb и т.д.
   
   

   Мораль

   
   Перед тем как зарываться в детали реализации, подумайте, как вы это все будете тестировать. Может быть, еще нет достаточно требований, чтобы реализовать ту или иную feature, и тогда её следует отложить на более позднее время (спринт). Закладывайте время на написание функциональных тестов, следите за регрессией на Continious Integration. Зеленые функциональные тесты это доказательство, что вы сделали свою работу правильно, так, как того хотел заказчик, и об этом вы узнаете сразу после очередного комита в Source Control (early feedback). И пишите вразумительные логи.
   Удачи вам.