TDD в большом проекте: с чего начать? - PullRequest
3 голосов
/ 19 августа 2009

Простой вопрос. Давайте на секунду наденем шапку нашего инженера / менеджера проекта:

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

Как начать подготовку модулей для реализации другими разработчиками? Вы начинаете писать интерфейсы или начинаете писать тесты? Вы смешиваете n 'match?

Как бы вы изменили свой ответ, если бы у вас была команда ветеранов-программистов? Команда менее опытных людей? Изменит ли ваша среда программирования ваши решения?

Ответы [ 5 ]

5 голосов
/ 19 августа 2009

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

Сами разработчики будут писать модульные тесты - функциональные / приемочные тесты - это отдельная проблема, которая может быть (частично) написана до начала работы.

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

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

1 голос
/ 20 августа 2009

TDD не точно , что вы ищете. TDD происходит в начале проекта и стимулирует разработку, следовательно, Test Driven Development.

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

  • Начните с малого. Не пытайтесь получить 100% охват всего проекта, выберите один класс или один набор функций и начните с него.

  • Импульс будет заключаться в том, чтобы начать с самого маленького / самого простого класса / функций, просто чтобы получить быстрые победы и иметь покрытие кода на уровне 100% для одного файла. Не.

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

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

  • После того, как вы написали несколько тестов, выполняйте их непрерывно. Нет смысла проводить тесты, если они все сломаны и / или не запускаются.

Да, у вас нет 100% покрытия кода, но вы можете постоянно и регулярно применять все больше и больше тестов, и после дюжины ошибок или около того у вас будет довольно много полезных тестов. И что еще более важно, вы будете получать все больше и больше тестов в «худших» или самых проблемных областях системы. Мы делаем это сейчас с web2project: http://caseysoftware.com/blog/unit-testing-strategy-web2project.

1 голос
/ 19 августа 2009

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

Во-первых, я бы спросил, что вы подразумеваете под «большим» проектом? Я видел, как некоторые люди отмечают, что проект занимает несколько месяцев и привлекает 4-5 программистов как «большой проект». Для других «большой проект» означает многолетнюю продолжительность и 30 или 40 разработчиков. Я предполагаю, что это где-то посередине, учитывая, что вы упомянули «нескольких разработчиков». Чтобы быть в безопасности, давайте предположим, что это длится от полугода до года с 5-10 девайсами.

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

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

Самым большим препятствием для использования TDD в проекте с несколькими разработчиками является отсутствие опыта в методологии. Дайте вашим программистам конкретный пример (даже если он немного функциональный), который действительно показывает им, как это сделать правильный путь , взаимодействовать с людьми, когда они приходят в проект, регулярно просматривать отзывы людей тесты, и убедитесь, что это продолжает оставаться темой, которая находится на переднем крае того, что вы делаете, а не просто запоздалая мысль. Если вы делаете Scrum, включите его в определение «готово» для любой задачи / истории.

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

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

1 голос
/ 19 августа 2009

Если у вас есть хорошая функциональная спецификация, я бы разделил работу ... и начал работать над тестовыми примерами.

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

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

0 голосов
/ 19 августа 2009

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

...