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

Як я це розумію, Test-Driven Development - це написання тестів для визначення специфікацій програми (ви можете виправити мене, якщо я помиляюся).

Якщо хтось відповідає за написання специфікацій (включаючи загальнодоступний API) для цього програмного забезпечення (назвемо його архітектором програмного забезпечення), чи означає це, що архітектор програмного забезпечення повинен написати всі тести?

Або Software Architect записує технічні характеристики, а потім передає їх розробникам, щоб написати тести проти?

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

architecture tdd

— Роберт Харві
джерело

На

— english.se

@Jose: Останнє речення в моїй ОП має на увазі трохи злегка щокою, оскільки мені здається очевидним, що програма завжди повинна мати детальні технічні характеристики від замовника. Але клієнти не завжди знають, чого саме хочуть, тому існують ітеративні процеси розробки програмного забезпечення . Дивіться тут для отримання додаткової інформації про метафору "зростаючого програмного забезпечення".

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

Відповіді:

Test-Driven Development - це написання тестів для визначення специфікацій програми

Ви не пишете тести для визначення специфікації, описи тестів, розповіді користувачів та описи функцій - це специфікація в розумінні «мертвих дерев».

Для перегляду, процес TDD у двох словах:

визначити проект з точки зору особливостей
опишіть зацікавлених сторін, поведінку та мету кожної функції за допомогою розповідей користувачів
вкажіть очікувані дані, ініціюючі події / умови та поведінку / результати, пов'язані з історією користувача, використовуючи описи тестів [і цим завершується "специфікація"]
вибрати набір функцій для кожної ітерації; ітерації повинні бути короткими [я опускаю кроки планування та оцінки для стислості]
- кодуйте тест для функції (вона не вдасться, але вам довелося приймати рішення API, щоб кодувати тест)
- реалізуйте достатньо функції, щоб тест пройшов
- refactor код при необхідності
- повторюйте з наступним тестом, поки функція не буде завершена
- повторюйте з наступною функцією до завершення ітерації
повторюйте з наступною ітерацією, поки проект не буде завершено

те, що дизайн, архітектура, супровідна документація та ін., які ви вирішили зробити, не є частиною TDD. Є кілька практичних «найкращих практик», про які можна прочитати, але пам’ятайте, що це «найкращі» практики в чужій майстерні , а не у вашій.

зауважте, що справа у тому, щоб замовник і розробник придумували можливості та писали розповіді та описи тестів разом для взаєморозуміння

тож, коли це не вийшло, первісне питання було:

яка роль архітектора програмного забезпечення в TDD?

І коротка відповідь:

Так само, як це було колись, таким, як це було колись. --Давид Бірн

EDIT: довга відповідь така: архітектор грає звичайні ролі прозорливого / слідчого / подразника / підтримки / зворотного стоп протягом усього процесу, за необхідності.

EDIT 2: Вибачте, що я пропустив пункт підпитання! Кожна відповідальність за написання специфікацій; всі розробники, включаючи архітектора, якщо / коли це необхідно, а також замовника . Розробники також кодують тести.

— Стівен А. Лоу
джерело

Це має сенс, але єдиними кроками, про які я коли-небудь чув, як люди розмовляють у контексті TDD, - це п’ять кроків у ваших п’яти кулях (описуючи процес червоно-зеленого рефактора). Чи справді залишилися кулі належать до TDD, або вони є частиною більш масштабної методології, як Agile або DDD?

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

@Robert hmmm ... гарне запитання! технічно інші кулі будуть XP; Я навчився XP та TDD одночасно і ніколи не думав їх розділяти. До цих пір ;-)

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

@Robert зробив кілька оновлених читань; дивіться правки (FYI, використовуючи XP ref extremeprogramming.org та TDD ref agiledata.org/essays/tdd.html#WhatIsTDD )

— Стівен А. Лоу,

Гм, посилання, яке ви надали для TDD, говорить про те, що TDD - це справді тестова конструкція. Тепер я повернувся з того, з чого почав. "Ви розробляєте органічно за допомогою запущеного коду, який забезпечує зворотний зв'язок між рішеннями."

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

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

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

Архітектор програмного забезпечення пише не всі тести. Це могло б занадто багато покласти на плечі однієї людини.

Архітектор програмного забезпечення повинен мати можливість накреслити початкову форму для API, щоб розробники потім писали тести для цього, а потім складали API. Однак у архітектора програмного забезпечення можуть бути різні стандарти коду, які не обов'язково перевіряються, наприклад, документація або умови іменування. Існує також можливість для початкового API пропустити деякі виклики, що в міру впровадження в API додаються нові дзвінки. Таким чином, API буде мати певний ріст, оскільки база коду зростає, але роль Архітектора полягає у наданні керівних принципів високого рівня та намагається забезпечити їх дотримання.

Звичайно, можуть бути випадки, коли команда може вирішити не мати архітектора програмного забезпечення, але залежно від масштабу API та компанії, що займається, це може бути, а може і не бути хорошою ідеєю.

— Дж. Б. Кінг
джерело