Какова роль архитектора программного обеспечения в процессе разработки через тестирование?

Насколько я понимаю, Test-Driven Development - это написание тестов для определения спецификаций программы (вы можете исправить меня, если я ошибаюсь).

Если кто-то отвечает за написание спецификаций (включая публичный API) для программного обеспечения (назовем его «Архитектор программного обеспечения»), означает ли это, что Архитектор программного обеспечения должен написать все тесты?

Или Архитектор программного обеспечения пишет спецификации, а затем передает их разработчикам для написания тестов?

Или вы позволяете спецификациям расти органично, позволяя всем разработчикам писать свои собственные тесты и забывать о наличии Software Architect?

architecture tdd

— Роберт Харви
источник

На сайте english.se ведутся споры о том, что вы подразумеваете под «органическим ростом» - english.stackexchange.com/questions/17853/… - хотите подтвердить :)

— JoseK

@Jose: последнее предложение в моем ОП должно быть слегка насмешливым, так как для меня очевидно, что программа всегда должна иметь подробные спецификации от клиента. Но клиенты не всегда точно знают, чего хотят, поэтому существуют итеративные процессы разработки программного обеспечения . Смотрите здесь для получения дополнительной информации о метафоре "растущего программного обеспечения".

— Роберт Харви

Ответы:

Разработка через тестирование - это написание тестов для определения спецификаций программы

Вы не пишете тесты для определения спецификации, описания тестов, пользовательские истории и описания функций являются спецификацией в смысле «мертвых деревьев».

Чтобы рассмотреть, процесс TDD в двух словах:

определить проект с точки зрения возможностей
опишите заинтересованную сторону, поведение и цель каждой функции, используя пользовательские истории
указать ожидаемые преимущества, инициирующие события / условия и поведение / результаты, связанные с пользовательской историей, используя описания тестов [и это завершает «спецификацию»]
выбрать набор функций для каждой итерации; итерации должны быть короткими [я опускаю шаги планирования и оценки для краткости]
- закодировать тест для функции (она потерпит неудачу, но вам пришлось принимать решения API для кодирования теста)
- реализовать достаточно функции, чтобы тест прошел
- рефакторинг кода при необходимости
- повторите со следующим тестом, пока функция не будет завершена
- повторите со следующей функцией, пока итерация не будет завершена
повторите со следующей итерацией, пока проект не будет завершен

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

обратите внимание , что точка является для заказчика и разработчика , чтобы придумать с особенностями и писать рассказы и описание тестов вместе , для взаимопонимания

Итак, с этим из пути, оригинальный вопрос был:

Какова роль архитектора программного обеспечения в TDD?

И короткий ответ:

Так же, как и всегда, так же, как и всегда. - Дэвид Бирн

РЕДАКТИРОВАТЬ: Длинный ответ: архитектор играет обычные роли провидца / исследователя / раздражителя / поддержки / поддержки в течение всего процесса, по мере необходимости.

РЕДАКТИРОВАТЬ 2: извините, я пропустил пункт подвопросов! Каждый несет ответственность за написание спецификаций; все разработчики, включая архитектора, если / когда это уместно, плюс заказчик . Разработчики также кодируют тесты.

— Стивен А. Лоу
источник

Это имеет смысл, но единственные шаги, о которых я когда-либо слышал, когда люди говорили в контексте TDD, - это пять шагов в ваших пяти внутренних пулях (описывающих процесс красно-зеленого-рефакторинга). Являются ли остальные патроны действительно частью собственно TDD, или они являются частью более обширной методологии, такой как Agile или DDD?

— Роберт Харви

@ Роберт Хммм ... хороший вопрос! технически другие пули были бы XP; Я изучил XP и TDD одновременно и никогда не думал отделить их. До сих пор ;-)

— Стивен А. Лоу

@Robert немного освежил чтение; см. правки (FYI с использованием XP ref extremeprogramming.org и TDD ref agiledata.org/essays/tdd.html#WhatIsTDD )

— Стивен А. Лоу

Хм, ссылка, которую вы указали для TDD, говорит о том, что TDD действительно является тест-ориентированным дизайном. Теперь я вернулся туда, откуда начал. «Вы проектируете органично, с работающим кодом, обеспечивающим обратную связь между решениями».

— Роберт Харви

@ Роберт, конечно, правки помогли мне лучше понять вопрос. Я беру D как развитие и интерпретирую его как весь жизненный цикл, а не только часть кода. TDDev - хороший способ выучить архитектурные навыки - рефакторинг имеет тенденцию подталкивать его в этом направлении

— Стивен А. Лоу

Архитектор программного обеспечения не пишет все тесты. Это было бы слишком много на плечах одного человека, на мой взгляд.

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

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

— JB King
источник