Следует ли применять TDD на начальной стадии прототипа? - PullRequest
2 голосов
/ 13 января 2012

У меня вопрос о применении tdd на ранних стадиях разработки. Часто, когда начинается разработка проекта, клиент не знает точно, каковы точные требования и, следовательно, меняет их после просмотра первых прототипов. Если мы применяем tdd с самого начала проекта, оказывается, что большая часть наших тестов (приемка, интеграция, модуль) будет вскоре либо удалена, либо обновлена. Это нормально? Если нет, как действовать на этом начальном этапе разработки продукта?

Ответы [ 4 ]

3 голосов
/ 13 января 2012

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

Так что не беспокойтесь, что некоторая часть ваших тестов пойдет в корзину вместе с реализацией, потому что она будет такой же на более поздних этапах. Что вы можете сделать как разработчик / BA / что угодно, это попытаться как можно быстрее указать им правильное направление, обсудить с ними что-то, чтобы вы не создавали слишком много «бесполезных» вещей.

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

Кроме того, тесты могут обновляться при изменении требований. Люди должны начать воспринимать тесты более серьезно (это srs business, k ?!) и осознавать, что это то, что: а) это не просто для того, чтобы раздражать вас, б) должно развиваться вместе с проектом, потому что это, скорее всего, спасет вас много неприятностей.

Прототипы, предложенные Ишаем, являются хорошим решением. Иногда. НО вам действительно нужно остерегаться. Во многих ситуациях, когда клиент видит прототип, который ему нравится / очень похож на то, что он хочет, он подумает: «Вау, ты почти готов! Когда мы сможем его запустить?»? И тогда им действительно сложно объяснить, что это всего лишь прототип и что вам нужно начинать с нуля. Во многих случаях люди просто начинают использовать прототип в качестве основного проекта, и им не хочется добавлять отсутствующие тесты или улучшать существующую кодовую базу. Именно так было создано приложение, с которым я сейчас работаю (уже более 10 лет!).

2 голосов
/ 13 января 2012

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

2 голосов
/ 13 января 2012

Да, это нормально.

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

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

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

0 голосов
/ 18 января 2012

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

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

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

Итак, мой метод:

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