Початок нового проекту з TDD

Я вивчаю TDD і читаю, що він також допомагає вам визначити дизайн додатка, правильно?

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

Я хочу створити просту систему реєстрації користувачів, яка запитає його ім’я, електронну адресу, країну (виберу одну зі списку) та номер телефону.

Тож питання ...

Я створив нове рішення у VS 2010, додав новий тестовий проект, і я просто не знаю, які тести написати!

Оскільки це допоможе мені визначити дизайн, які тести я можу написати тут?

Дякуємо за будь-яку допомогу!

Коли ви пишете одиничні тести, ви перевіряєте поведінку вашої програми, тому важливим питанням є те, що робить ваша програма ? Ось початок:

[TestFixture]
public class RegistrationTests
{
    [Test]
    public void Should_save_new_user_info()
    {
    }

    [Test]
    public void Should_throw_validation_exception_when_email_already_exists()
    {
    }

    [Test]
    public void Should_format_phone_number_when_country_code_is_us()
    {
    }
}

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

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

Коли ви визначаєте функцію, ви просто пишете щось на кшталт

When a user is saved
Then the user should exist

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

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

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

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

Кожній з цих підфункцій знадобиться список сценаріїв, який разом повністю визначає, чи працює функція чи ні, такі речі, як "Можна зберегти дійсного користувача" та "Неможливо зберегти користувача з подвійним ім'ям користувача".

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

Мені було б корисно створити резервні копії моїх перших експериментів в TDD з деяким читанням, а також вирізанням коду. Стаття у Вікіпедії на цю тему дуже гарна і приведе до вас найрізноманітніші інші ресурси. Шукайте речі Кента Бека, зокрема - батька TDD.

Ще одні речі, які можуть допомогти вам розібратися, - це робити деякі ката - прості, майже безглузді тренувальні вправи. У Роя Ошерово є кілька хороших.

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

А щоб розпочати, можливо, почніть з вашої вимоги до імені. Що вам потрібно?

Вам, напевно, потрібен клас. Напишіть тест для цього (деякі люди пропускають це, але коли починають робити це за вправою) і пишіть клас.

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

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

І так далі...

Я думаю, що неможливо дати вам ідею TDD у короткій відповіді. Вам потрібно "побачити" когось, хто це практикує, щоб відчути це. Найкращий ресурс, який я коли-небудь знаходив на цю тему, - http://pragprog.com/titles/achbd/the-rspec-book . Перш ніж сказати мені, що Рубі - це не ваша мова: прочитайте передмову дядька Боба! ;-)

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

Як ви описали систему, на рівні програми існує лише один тест:

[Тест] публічний недійсний Save_and_retrieve_user (ім'я рядка, рядок електронної пошти, ...) {// Зберегти // Отримати // Перевірити}

Коли ви уточнюєте вимоги, додайте більше тестів.