Продажа TDD [закрытой] команде

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

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

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

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

Что касается нерешительного товарища по команде, наберитесь терпения, дождитесь возможности, а затем атакуйте. В разработке программного обеспечения, несомненно, будет проблема, когда TDD предотвратил бы или смягчил проблему. Ищите такую ​​возможность. Работайте с ним / ней над созданием тестов, которые должны были быть разработаны с самого начала. Однако убедитесь, что вы составили свое сообщение таким образом, чтобы не смутить своего товарища по команде.

Я согласен с С. Лотт , вы не можете «продать» их, вам нужно показать ценность.

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

Первоначально TDD была для меня сложной концепцией, но теперь я не могу представить себе программирование каким-либо другим способом.

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

Не думаю, что он когда-либо использовал фразу "TDD", но там есть отличная информация.