Звуковий ДА з TDD (і за кількома винятками)
Суперечливо добре, але я стверджую, що кожен, хто відповість "ні" на це питання, не вистачає фундаментальної концепції TDD.
Для мене відповідь є надзвичайним так, якщо ви слідуєте TDD. Якщо ні, то ні, це правдоподібна відповідь.
DDD в TDD
TDD часто цитується як у вас основні переваги.
- Оборона
- Забезпечення коду може змінитися, але не його поведінка .
- Це дозволяє настільки важливу практику рефакторингу .
- Ви отримуєте цей TDD чи ні.
- Дизайн
- Ви вказуєте, що щось має робити, як воно має вести себе, перш ніж реалізувати це.
- Це часто означає більш обізнані рішення щодо впровадження .
- Документація
- Набір тестів повинен слугувати специфікацією (вимогами) документації.
- Використання тестів з цією метою означає, що документація та реалізація завжди знаходяться в узгодженому стані - зміна одного означає зміну іншому. Порівняйте з вимогами дотримання та оформленням на окремому документі слова.
Окрему відповідальність від впровадження
Як програмістам, страшенно спокусливо розглядати атрибути як щось важливе, а геттер і сетер - як якусь накладну.
Але атрибути - це детальна інформація про реалізацію, в той час як сеттери та геттери - це договірний інтерфейс, який фактично змушує програми працювати.
Набагато важливіше сказати, що об’єкт повинен:
Дозвольте своїм клієнтам змінити стан
і
Дозвольте своїм клієнтам запитувати його стан
то як насправді зберігається цей стан (для якого атрибут є найпоширенішим, але не єдиним способом).
Тест, такий як
(The Painter class) should store the provided colour
важливо для документаційної частини TDD.
Те, що можлива реалізація є тривіальною (атрибутивною) і не несе користі для оборони, вам не повинно бути невідомо, коли ви пишете тест.
Відсутність інженерної розвідки ...
Однією з ключових проблем у світі розробки системи є відсутність інтенсивної інженерії 1 - процес розробки системи роздроблений на розрізнені підпроцеси, артефакти яких (документація, код) часто суперечать.
1 Броді, Майкл Л. "Джон Мілопулос: пошиття насіння концептуального моделювання". Концептуальне моделювання: основи та програми. Спрингер Берлін Гейдельберг, 2009. 1-9.
... і як TDD це вирішує
Саме документаційна частина TDD гарантує, що технічні характеристики системи та її коду завжди відповідають.
Створіть спочатку, реалізуйте пізніше
У TDD ми спочатку пишемо невдалий тест на прийняття, лише потім пишемо код, який дозволяє їм пройти.
У BDD вищого рівня ми спочатку пишемо сценарії, а потім пропускаємо їх.
Чому слід виключати сетери та геттери?
Теоретично в TDD цілком можливо, щоб одна людина написала тест, а інша реалізувала код, який робить його проходженням.
Тож запитайте себе:
Якщо особа, яка пише тести для класу, повинна згадати про геттерів та сетер.
Оскільки getters та setters є загальнодоступним інтерфейсом для класу, відповідь, очевидно, так , інакше не буде можливості встановити або запитати стан об'єкта.
Очевидно, що якщо ви пишете код спочатку, відповідь може бути не такою чіткою.
Винятки
Є кілька очевидних винятків із цього правила - функції, які є чіткими деталями впровадження та явно не є частиною дизайну системи.
Наприклад, локальний метод 'B ()':
function A() {
// B() will be called here
function B() {
...
}
}
Або приватна функція square()тут:
class Something {
private:
square() {...}
public:
addAndSquare() {...}
substractAndSquare() {...}
}
Або будь-яка інша функція, яка не є частиною publicінтерфейсу, який потребує написання в дизайні системного компонента.