TDD і контроль версій

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

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

2. Я знаходжу помилку і пишу тест, щоб відтворити її. Чи повинен я здійснити невдалий тест або здійснити виправлення помилки, а потім здійснити?

Це два приклади, які відразу приходять на думку. Сміливо надайте додаткові приклади у своїй відповіді.

Редагувати:

В обох прикладах я зробив припущення, що одразу після написання тесту я напишу код, щоб тест пройшов. Можливо, виникла й інша ситуація: я працюю над проектом, використовуючи TDD, кілька годин без зобов'язань. Коли я, нарешті, беру на себе зобов’язання, я хочу розбити свою роботу на невеликі шматки. (Git робить це порівняно просто, навіть якщо ви хочете зробити лише деякі зміни в одному файлі.)

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

Чи повинен я зробити тест перед написанням класу, хоча тест навіть не складається? Або я повинен заглушити мінімальну кількість коду, необхідного для складання тесту, перш ніж зробити його?

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

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

Ні, не робіть невдалого тесту. Закон ЛеБланка зазначає:

Пізніше дорівнює ніколи.

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

Також стиль розробки TDD повідомляє:

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

Якщо ви перевірили невдалий тест, це означає, що ви не завершили цикл.

¹ Коли я сказав, що я зобов'язуюся, я мав на увазі дійсно зобов’язатись до магістралі (для користувачів git натисніть свої зміни, щоб інші розробники отримали їх).

Чи повинен я зробити тест перед написанням класу, хоча тест навіть не складається?

Ні.

Чи повинен я здійснити невдалий тест

Ні.

Тут ви говорите про дві парадигми:

1. тестова розробка - яка нічого не говорить про вчинення коду. Дійсно, він розповідає про те, як писати код і коли ви закінчите. Тож я вважаю, що кожен "зроблений" є кандидатом на зобов'язання.
2. спритний розвиток, зокрема: "здійснювати рано і часто" (що не вимагає TDD). Ідея цього полягає в тому, щоб якнайшвидше інтегруватись з іншими компонентами в систему і таким чином отримувати ранні відгуки. Якщо ви здійснюєте локальну програму DVCS, а не натискаєте, це не має сенсу в цьому сенсі. Місцеві зобов’язання допомагають розробникам лише структурувати свою роботу.

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

Для великого виправлення помилку виконайте після кожного покращення (наприклад, рефакторинг), навіть якщо помилка ще не виправлена. Тести повинні бути зеленими, але код повинен збиратися.

Звичайно, ви починаєте з використання здорового контролю джерел, як git.

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

Потім перед тим, як виштовхувати матеріал, ви розбийте всю роботу в один комітет. Або пара, в точках, де все зелене і композиція має сенс. І підштовхуйте до цих розумних зобов'язань. Для кратного випадку зробіть це гілкою, яку ви з’єднаєте з --no-ff.

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

Це моє розуміння світу зобов’язується позначити точку, до якої, можливо, хочеться повернутися. Точка a, яку тест не дає (але компілює), безумовно, є одним із таких моментів. Якби я блукав у неправильному напрямку, намагаючись зробити тестовий пропуск, я б хотів повернути код до початкової точки і спробувати ще раз; Я не можу цього зробити, якщо не зробив.

Чи повинен я зробити тест перед написанням класу, хоча тест навіть не складається?

Із розгалужуваним SCM (я бачив, як ви використовуєте Git), ви повинні здійснювати кожен раз, коли вам потрібна точка резервного копіювання ("я щось накрутив; я скину робочу діру до останньої точки резервної копії") або коли у вас є стабільна версія. Коли у вас є стабільна версія (всі тести пройшли), ви також повинні розглянути можливість об'єднання поточної гілки функцій у вашу основну галузь розвитку.

Або я повинен заглушити мінімальну кількість коду, необхідного для складання тесту, перш ніж зробити його?

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

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

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

Це два приклади, які відразу приходять на думку. Сміливо надайте додаткові приклади у своїй відповіді.

Редагувати:

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

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

Можливо, виникла й інша ситуація: я працюю над проектом, використовуючи TDD, кілька годин без зобов'язань. Коли я, нарешті, беру на себе зобов’язання, я хочу розбити свою роботу на невеликі шматки. (Git робить це порівняно просто, навіть якщо ви хочете зробити лише деякі зміни в одному файлі.) Це означає, що моє запитання стосується того, що робити, як і про те, коли потрібно зробити.

Я б сказав, безумовно, зобов'язуюся створювати резервні бали . Це дуже добре працює для дослідницького тестування ("Я просто додаю кілька відбитків у базу коду, запустіть та git reset --hardвидаляю їх, коли закінчу") та для складання прототипів.

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

З точки зору TDD, питання: "Ви спочатку замовте тест?" повністю залежить від коду, над яким ви працюєте. Якщо це новий код, ви нічого не входите в дію, доки не будете мати щось, що вартує реєстрації. Але якщо це помилка, знайдена у вже складеному або відправленому коді, варто перевірити тест на відтворення помилки НА САМОМУ САМОМУ, якщо це закінчився робочий день, і ви вийдете з офісу перед тим, як виправити кодекс.

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