Коли ви пишете "реальний" код в TDD?

Усі приклади, які я читав і бачив у навчальних відео, мають спрощені приклади. Але те, що я не бачу, як зробити "справжній" код після того, як я позеленію. Це частина "Refactor"?

Якщо у мене досить складний об'єкт зі складним методом, і я пишу свій тест і мінімальний мінімум, щоб він пройшов (після того, як він вперше виходить з ладу, Червоний). Коли я повернусь назад і напишу реальний код? І скільки реального коду я пишу перед тим, як повторно перевірити? Я здогадуюсь, що останній - це більше інтуїція.

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

У своєму дизайні у мене є архітектура, з якої я хочу розпочати, Історії користувачів тощо. Звідси я беру ці Історії користувачів і створюю тест, щоб перевірити Історію користувачів. Користувач каже: У нас люди вступають до школи та сплачують реєстраційні внески. Отже, я думаю про спосіб зробити це невдалим. Роблячи це, я проектую тестовий клас для X класу (можливо, студента), який не зможе. Потім я створюю клас "Учень". Можливо, "Шкільну" я не знаю.

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

Я порівнював це з думкою про рекурсію. Рекурсія не є важким поняттям. Це може бути важче насправді відстежувати це в голові, але насправді найскладніше - це знати, коли рекурсія «ламається», коли зупинятись (моя думка, звичайно.). Тому я повинен думати про те, що зупиняється рекурсія першою. Це лише недосконала аналогія, і вона передбачає, що кожна рекурсивна ітерація - це "пропуск". Знову лише думка.

У впровадженні Школи важче бачити. Числові та банківські книги є "простими" в тому сенсі, що ви можете використовувати просту арифметику. Я можу побачити + b і повернути 0 і т. Д. У випадку з системою людей мені доводиться більше думати над тим, як це здійснити . У мене є концепція провалу, проходу, рефактора (здебільшого через навчання та це питання.)

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

Або, можливо, це показує, що я все ще плутаюся.

Якщо у мене досить складний об'єкт зі складним методом, і я пишу свій тест і мінімальний мінімум, щоб він пройшов (після того, як він вперше виходить з ладу, Червоний). Коли я повернусь назад і напишу реальний код? І скільки реального коду я пишу перед тим, як повторно перевірити? Я здогадуюсь, що останній - це більше інтуїція.

Ви не «повертаєтесь назад» і не пишете «реальний код». Це все реальний код. Що ви робите, - це повернутися назад і додати ще один тест, який змушує вас змінити код, щоб зробити новий тест-пропуск.

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

Помітили шаблон?

Давайте пройдемося (ще) простий приклад у надії, що це допоможе.

Assert.Equal("1", FizzBuzz(1));

Легкий горох.

public String FizzBuzz(int n) {
    return 1.ToString();
}

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

Assert.Equal("2", FizzBuzz(2));

Ми могли б зробити щось нерозумно if n == 1, але ми перейдемо до розумного рішення.

public String FizzBuzz(int n) {
    return n.ToString();
}

Класно. Це буде працювати для всіх номерів, які не є FizzBuzz. Що наступного вводу, який змусить змінити виробничий код?

Assert.Equal("Fizz", FizzBuzz(3));

public String FizzBuzz(int n) {
    if (n == 3)
        return "Fizz";
    return n.ToString();
}

І знову. Напишіть тест, який ще не пройде.

Assert.Equal("Fizz", FizzBuzz(6));

public String FizzBuzz(int n) {
    if (n % 3 == 0)
        return "Fizz";
    return n.ToString();
}

І тепер ми охопили всі кратні три (це також не кратні п'ять, ми це відзначимо і повернемося).

Ми ще не написали тест для "Buzz", тому напишемо це.

Assert.Equal("Buzz", FizzBuzz(5));

public String FizzBuzz(int n) {
    if (n % 3 == 0)
        return "Fizz";
    if (n == 5)
        return "Buzz"
    return n.ToString();
}

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

Assert.Equal("Buzz", FizzBuzz(10));

public String FizzBuzz(int n) {
    if (n % 3 == 0)
        return "Fizz";
    if (n % 5 == 0)
        return "Buzz"
    return n.ToString();
}

І тепер ми можемо обробляти всі кратні 5, які також не кратні 3.

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

private bool isDivisibleBy(int divisor, int input) {
    return (input % divisor == 0);
}

public String FizzBuzz(int n) {
    if (isDivisibleBy(3, n))
        return "Fizz";
    if (isDivisibleBy(5, n))
        return "Buzz"
    return n.ToString();
}

Класно. Тепер ми видалили дублювання та створили добре названу функцію. Який наступний тест ми можемо написати, який змусить нас змінити код? Ну, ми уникали випадку, коли число ділиться і на 3, і на 5. Давайте запишемо його зараз.

Assert.Equal("FizzBuzz", FizzBuzz(15));

public String FizzBuzz(int n) {
    if (isDivisibleBy(3, n) && isDivisibleBy(5, n))
        return "FizzBuzz";
    if (isDivisibleBy(3, n))
        return "Fizz";
    if (isDivisibleBy(5, n))
        return "Buzz"
    return n.ToString();
}

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

public String FizzBuzz(int n) {

    var isDivisibleBy3 = isDivisibleBy(3, n);
    var isDivisibleBy5 = isDivisibleBy(5, n);

    if ( isDivisibleBy3 && isDivisibleBy5 )
        return "FizzBuzz";
    if ( isDivisibleBy3 )
        return "Fizz";
    if ( isDivisibleBy5 )
        return "Buzz"
    return n.ToString();
}

І ми висвітлювали кожен розумний внесок, а як бути з необґрунтованим внеском? Що станеться, якщо ми пройдемо 0 або мінус? Напишіть ці тестові приклади.

public String FizzBuzz(int n) {

    if (n < 1)
        throw new InvalidArgException("n must be >= 1);

    var isDivisibleBy3 = isDivisibleBy(3, n);
    var isDivisibleBy5 = isDivisibleBy(5, n);

    if ( isDivisibleBy3 && isDivisibleBy5 )
        return "FizzBuzz";
    if ( isDivisibleBy3 )
        return "Fizz";
    if ( isDivisibleBy5 )
        return "Buzz"
    return n.ToString();
}

Це починає виглядати як "реальний код" ще? Що ще важливіше, в який момент він перестав бути "нереальним кодом" і перейшов до "реального"? Це над чим задуматися ...

Отже, я зміг це зробити, просто шукаючи тест, який я знав, що не пройде на кожному кроці, але я мав багато практики. Коли я працюю, речі ніколи не бувають такими простими, і я не завжди можу знати, який тест призведе до змін. Іноді я напишу тест і буду здивований, побачивши, що воно вже проходить! Я настійно рекомендую вам звикнути створювати "Тестовий список" перед тим, як розпочати роботу. Цей тестовий список повинен містити всі "цікаві" матеріали, які ви можете придумати. Ви можете використовувати їх не всі, і ви, ймовірно, будете додавати справи, коли ви переходите, але цей список служить дорожньою картою. Мій тестовий список для FizzBuzz виглядав би приблизно так.

• Негативний
• Нуль
• Один
• Два
• Три
• Четверо
• П’ять
• Шість (нетривіальне кратне 3)
• Дев'ять (3 квадрата)
• Десять (нетривіальне кратне 5)
• 15 (кратні 3 і 5)
• 30 (нетривіальне кратне 3 і 5)

"Реальний" код - це код, який ви пишете, щоб зробити свій тестовий пропуск. Дійсно . Це так просто.

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

Ідея кроку рефактора - це просто очистити те, що ви написали, як тільки ви щасливі, що це відповідає вимогам.

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

Коротка відповідь полягає в тому, що "реальний код" - це код, який робить тестовий прохід. Якщо ви можете зробити тестовий пропуск за допомогою іншого, крім реального коду, додайте більше тестів!

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

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

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

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

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

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

Боб Мартін це чудово пояснює тут .

Частина рефактора очищується, коли ви втомилися і хочете їхати додому.

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

Це може бути таким же простим, як перейменування GreetImplдо GreetWorldстворення GreetMomкласу (після додавання тесту), щоб додати функцію, яка надрукує "Привіт мамо".

Але справжній код з'явиться на етапі рефактора фази TDD. Тобто код, який повинен бути частиною остаточного випуску.

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

Девізом життєвого циклу TDD було б: ЧЕРВЕНИЙ ЗЕЛЕНИЙ РЕФАКТОР

ЧЕРВОН : Напишіть тести

ЗЕЛЕНИЙ : Зробіть чесну спробу отримати функціональний код, який проходить тести якнайшвидше: дублікат коду, незрозуміло названі змінні хаки вищого порядку тощо.

РЕФАКТОР : Очистіть код, належним чином назвіть змінні. НАДУВАЙТЕ код.

Коли ви пишете "реальний" код в TDD?

Червона фаза , де писати код.

На етапі рефакторингу головна мета - видалення коду.

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

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

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

Це не червоно-рефактор, це червоно-зелений-рефактор. - Роб Кіньйон

Дякуємо, що вказали на це.

Отже, це зелена фаза, коли ви пишете реальний код

У червоній фазі ви пишете специфікацію виконуваного файлу ...

Ви постійно пишете Реальний код .

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

Ви думаєте, що ви не пишете корисного ( справжнього ) коду, тому що за мить ви можете переробити його.

Редакторинг коду - це процес реструктуризації існуючого комп'ютерного коду - зміна факторингу - без зміни зовнішньої поведінки.

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

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

Коли я читав Книгу (*) на TDD, для мене найважливішою особливістю був: список TODO. Це показало мені, що TDD - це також техніка, яка допомагає розробникам зосередитися на одній справі. Тож це також відповідь на Ваше запитання перед тим, скільки реального коду потрібно написати ? Я б сказав достатньо коду, щоб зосередити увагу на одній речі одночасно.

(*) «Розробка тестових процесів: за прикладом» Кента Бека

Ви не пишете код, щоб зробити тести невдалими.

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

Вся справа в написанні початково невдалих тестів полягає в тому, щоб зробити дві речі:

1. Покрийте всі справи - усі іменні регістри, усі крайові справи тощо.
2. Підтвердьте свої тести. Якщо ви коли-небудь бачите, як вони проходять, як ви можете бути впевнені, що вони надійно повідомлять про помилку, коли це станеться?

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

На мій власний досвід (C # /. NET), чистий тест-перше - це трохи недосяжний ідеал, тому що ви не можете скласти виклик до методу, який ще не існує. Отже, "тест спочатку" - це дійсно спочатку кодування інтерфейсів та реалізація заглушки, а потім написання тестів проти заглушок (які спочатку будуть відмовлені), поки заглушки не будуть належним чином сформовані. Я ніколи не пишу "провальний код", просто будую із заглушок.

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

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

У коді, який я написав, інтеграційні тести бібліотеки з різними тестовими програмами, які читають дані та передають їх у бібліотеку, а потім перевіряють результати. Потім я це роблю нитками. Потім я це роблю з нитками та виделкою () посередині. Потім я запускаю його і вбиваю -9 через 2 секунди, потім запускаю його і перевіряю його режим відновлення. Я це розмиваю. Я катую це всілякими способами.

ВСЕ ТЕБЕ ТАКОЖ тестування, але у мене немає досить червоного / зеленого дисплея для результатів. Це або вдається, або я перекопаю кілька тисяч рядків коду помилки, щоб з’ясувати, чому.

Ось де ви перевіряєте "реальний код".

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

У відповідь на назву питання: "Коли ви пишете" справжній "код в TDD?", Відповідь: "навряд чи колись" або "дуже повільно".

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

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

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

Але вам потрібно знати, як зламати свою програму, щоб мати можливість створити гідний код. Наприклад, якби ви не знали про Таблицю Little Bobby (xkcd 327), ви, ймовірно, не санітували б свої дані, перш ніж працювати з базою даних, тому ви б не змогли захистити свої дані навколо цієї концепції.

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

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

Будь ласка, не потрапляйте в цю пастку і перегляньте свою роль кодування того, що це таке - завдання кодера полягає виключно у створенні коду. Код, який працює дуже добре. Тепер пам’ятайте, що ви будете на годиннику як професійний кодер, і вашому клієнту буде байдуже, чи ви написали 100 000 тверджень, або 0. Вони просто хочуть, щоб код працював. Насправді добре, насправді.