TDD: Що відбувається перед першим тестом на одиницю?

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

Скажімо, я хочу написати додаток, щоб допомогти нашій родині керувати своїми завданнями. Ось кілька запитань на мою думку: Як перейти від цієї ідеї до мого першого тесту? Скільки слід вирішити, перш ніж почати, і скільки я зрозуміти після того, як почну писати тести? Коли я приймаю рішення, як зберігати дані в текстовому файлі чи базі даних? Чи потрібно проходити тести прийняття користувача перед тим, як розпочати роботу? Чи повинен я створити інтерфейс користувача? Чи повинен у мене бути специфікація? (Я розумію, що принаймні деякі з цих прикладів питань, мабуть, знаходяться в "сірій області").

На додаток до основного питання про тест до першого тесту, можна також навести приклад того, як може виглядати тест першого блоку для такого проекту, як зразок проекту?

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

Подумайте над дизайном трохи, потім виберіть тестовий опис і починайте кодування: червоно-зелений-рефактор.

Повторюйте, поки не пройдуть всі тести.

Так, прийняття тестів слід розглядати як частину цього, прикріпленого до відповідної історії.

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

Розробники, які не використовують TDD, теж повинні задуматися над цим - але вони можуть "просто зануритися" і почати писати щось, що завгодно. Але "щось, що завгодно" не завжди стоїть на шляху до реалізації програми, яку ви думали, що збираєтесь написати. Що? Ну, як виглядала б ваша програма, якби вона працювала? Які тести він би пройшов?

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

Класно. Якби ця програма працювала, що б це робило? Що ж, хору можна було б призначити особі, правда?

Person fred = new Person("fred")
Chore mow = new Chore("mow the lawn");
mow.assignTo(fred);
assertEquals(fred, mow.whoIsAssigned());

Там старт. Не місце, з якого ви повинні почати, не обов’язково найкраще місце для початку - але це місце. Ви хочете, щоб ваш код підтримував (хоча я впевнений, що ви можете придумати кращі імена). Починайте там, дивіться, як це не виходить. Нехай це проходить. Почистіть його. Натріть, промийте, повторіть.

Так, TDD має цю проблему. Ось чому я зараз рекомендую розвиток, керований поведінкою.

Почніть вручну. Запишіть щось схоже на історію користувача:

• Як користувач
• Коли я вибираю Додати в кошик, я хочу, щоб продукт був доданий прозоро у фоновому режимі
• Так що я можу продовжувати свій покупок безперервно

Тепер, які функції підтримують цю мету (частина "Так що")?

• Коли товар додається в кошик для покупок
  • Кошик для користувача буде містити новий товар
  • Загальна кількість товарів у кошику збільшиться на одиницю
  • Користувача не слід переадресовувати
  • Буде доступний варіант перевірки зараз
• Коли в кошику для покупок є два предмети, і користувач вирішує перевірити
  • Користувача буде переспрямовано на сторінку перевірки
  • Обидва елементи будуть видні

Це все, що можна, і слід перевірити вручну.

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

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

У Ruby є огірок для автоматичного тестування та rspec для тестування API нижчого рівня

У Javascript є жасмін і qUnit.

крапка крапка

Як перейти від цієї ідеї до мого першого тесту? Скільки слід вирішити, перш ніж почати, і скільки я зрозуміти після того, як почну писати тести?

Розбийте свою програму на історію розміру. ("Як користувач, я хочу двічі клацнути по значку та запустити програму." Або "Як користувач, я хочу відкрити свій браузер і перейти до програми. Що б там не було."

Потім розбийте розповідь на деякі завдання. (наприклад, Створіть проект у Eclipse, налаштуйте сховище коду) Коли ви перейдете до завдання кодування, напишіть свій перший тест.

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

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

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

Для отримання додаткової інформації про TDD я рекомендую розробити тестові розробки за прикладом від Кента Бека. У нього також є скріншот TDD, який слідкує за розвитком нетривіальної бібліотеки в чистому стилі TDD з поясненнями Кента на кожному кроці процесу. Я думаю, що це чудовий приклад TDD на практиці, навіть якщо це робиться (за необхідності) у надуманому середовищі.

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

Промийте, повторіть тощо.

Для мене це важливе мислення про те, як би ви протестували його, і це те, що може керувати вашим дизайном.