Я експериментую з тестовою розробкою, і я виявив, що часто стикаюся з такою ситуацією:

1. Я пишу тести на деяку функціональність X. Ці тести виходять з ладу.
2. Намагаючись реалізувати X, я бачу, що мені потрібно реалізувати деяку функцію Y у нижньому шарі свого коду. Так...
3. Я пишу тести на Y. Зараз обидва тести на X і Y провалюються.

Колись у мене одночасно працювали 4 функції в різних шарах коду, і я втрачав увагу на тому, що я насправді роблю (занадто багато тестів не вдалося одночасно).

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

Що мені робити в таких випадках? Чи має TDD якісь рекомендації?

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

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

З іншого боку, можливо, найкращим підходом є лише один (невдалий) тест, який веде наступну зміну.

Інші тести, орієнтовані на код, який спирається на нову функціональність, можуть бути тимчасово відключені, оскільки на даний момент вони не є актуальними, тобто. у вашому випадку відключіть тести для X, поки ви не реалізуєте Y тощо.

Таким чином, ви можете зберегти свою увагу на наступній зміні, лише те, чого ви хочете, я думаю.

Стій

Це здається, що тут можуть бути два окремих питання:

1. ви забули деякі історії та тестові сценарії та не відкрили їх, поки не почали працювати над певним тестовим сценарієм та / або

2. ви фактично проводите тестування одиниць, а не тестування функцій TDD

Для №1 зупиніться , поверніться та оновіть історії та тестові сценарії, а потім почніть із іншого сценарію.

Для №2 зупиніться і пам’ятайте, що ви тестуєте функції, а не одиниці, тому використовуйте макети, щоб промальовувати інші інтерфейси та / або впроваджувати більше коду, щоб зробити тестовий пропуск без додавання нових тестових сценаріїв. Це передбачає, що ви не пропускаєте тестові сценарії, але натомість - і це дійсно часто - поєднуючи тестування модулів та TDD.

Це велике запитання і величезне розчарування для мене, як і TDD. Мені здається, що TDD не вистачає в цьому сценарії, коли ви просто не можете знати, які компоненти або функції нижчого рівня вам знадобляться, поки ви не почнете розробляти.

Особисто я виявив, що TDD працює лише в тому випадку, якщо ви точно знаєте, що вам потрібно зробити і що потрібно викликати, щоб виконати функцію. Розробники не завжди знають усе, перш ніж ми починаємо, тому я виявив, що найкращий спосіб пом'якшити ситуацію, яку ви описуєте:

Прототип

Коли я роблю прості програми-прототипи для вивчення та виявлення методів та підходів до технічної проблеми, я виявляю багато роботи з ногами і отримую це дослідження з шляху, перш ніж починати. Проектування та оцінка також набагато простіше.

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

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

Це залежить від того, які тести ви пишете, роблячи TDD.

Класична модель полягає в написанні одиничних тестів і використанні макетів або заглушок для від'єднання тесту від інших "одиниць" коду.

Існує багато інших альтернативних моделей, таких як ATDD, де випробовується повний стек або майже повний тест стека. У цьому конкретному випадку ваші тести письма, які стверджують, вимагають поведінки програми, не однієї одиниці коду, щоб ви не писали інших тестів. Ви отримаєте реалізацію туди-назад, щоб задовольнити тест. Потім ви додаєте інші тести на інші особливості / поведінку.