TDD проти продуктивності

У своєму теперішньому проекті (грі, на C ++) я вирішив, що під час розробки я буду використовувати тестово керовану розробку на 100%.

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

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

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

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

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

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

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

• Час / продуктивність: Написання тестів відбувається повільніше, ніж не написання тестів. Якщо ви обмежите це, я погодився б. Однак якщо ви докладете паралельних зусиль, коли застосовуєте не-TDD підхід, велика ймовірність, що час, який ви витратите на розрив-виявлення-налагодження та виправлення існуючого коду, поставить вас у чистий мінус. Для мене TDD - це найшвидший показник, який я можу пройти без шкоди для своєї впевненості в коді. Якщо ви знайдете речі у своєму методі, які не мають додаткової цінності, усуньте їх.
• Кількість тестів: Якщо ви кодуєте N речей, вам потрібно перевірити N речей. перефразовуючи один із рядків Кента Бека " Тестуйте лише, якщо ви хочете, щоб він працював ".
• Застрягати годинами: я теж (іноді, а не> 20 хвилин, перш ніж зупиняти лінію). Це просто ваш код, який говорить вам, що дизайн потребує певної роботи. Тест - це ще один клієнт для вашого класу SUT. Якщо у тесті важко використовувати тип, швидше за все, будуть і ваші виробничі клієнти.
• Подібні тестування тесту: Для написання контргументу мені потрібен ще якийсь контекст. Це сказав: Стоп і подумай про схожість. Чи можете ви якось керувати цими тестами на даних? Чи можна писати тести на базовий тип? Тоді потрібно просто запустити один і той же набір тестів проти кожної деривації. Слухайте ваші тести. Будьте правильним виглядом лінивих і подивіться, чи зможете винайти спосіб уникнути тугі.
• Перестати думати, що вам потрібно зробити далі (тест / специфікація) - це не погано. Навпаки, рекомендується, щоб ви будували «правильну річ». Зазвичай, якщо я не можу придумати, як його протестувати, я зазвичай не можу також придумати реалізацію. Хороша ідея звільнити ідеї впровадження, поки ви не потрапите. Можливо, більш просте рішення буде затьмарене передумовим дизайном YAGNI-ish.

І це підводить мене до остаточного запиту: як мені стати краще? Моя (або An) відповідь - читати, розмірковувати та практикувати.

наприклад, пізно, я продовжую вкладки

• чи відображає мій ритм RG [Ref] RG [Ref] RG [Ref] чи це RRRRGRRef.
• % часу, витраченого в режимі помилок Red / Compile.
• Я застряг у стані Red / Broken build?

Вам не потрібно 100% -ве покриття тесту. Будьте прагматичними.

TDD все ще значно уповільнює мене

Це насправді помилково.

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

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

Минулий час, ймовірно, буде однаковим. Програмне забезпечення TDD буде значно кращої якості.

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

Це змушує мене замислитися, скільки ви дотримуєтесь кроку TDD "Refactor".

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

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

Кілька філософських моментів про TDD, які можуть бути корисними:

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

EDIT: На тему філософії одиничного тестування, я думаю, це може бути цікавим для вас, щоб прочитати: Шлях Тестівуса

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

• Ви згадуєте C ++ як мову свого розвитку. Я широко практикував TDD на Java, використовуючи чудові бібліотеки, такі як JUnit та Mockito. Однак я виявив, що TDD в C ++ дуже неприємно через відсутність бібліотек (зокрема, глузуючих фреймворків). Хоча цей момент не дуже допомагає тобі у вашій нинішній ситуації, я сподіваюся, що ви це врахуєте перед тим, як взагалі скинути TDD.

Дуже цікаве запитання.

Що важливо відзначити, це те, що C ++ не дуже легко перевірити, а ігри, загалом, також є дуже поганим кандидатом на TDD. Ви не можете перевірити, чи OpenGL / DirectX малює трикутник червоним кольором з драйвером X, а жовтим - з драйвером Y легко. Якщо нормальна векторна збірна карта не перегортається після перетворення шейдера. Ви також не можете перевіряти проблеми із відсіканням на версії драйверів з різною точністю тощо. Невизначена поведінка малювання через неправильні дзвінки також може бути перевірена лише за допомогою точного огляду коду та SDK. Звук також поганий кандидат. Багатопотокове читання, що знову ж таки є досить важливим для ігор, є досить марним для тестування одиницями. Так що важко.

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

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

Знову ж таки, я не гуру TDD або євангеліст, тому прийміть все це з зерном солі.

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

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

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

Я погоджуюся з іншими відповідями, але хочу також додати дуже важливий момент: Рефакторинг коштує !!

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

Як інші люди виживають TDD, не вбиваючи всієї продуктивності та мотивації?

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

TDD - це смирення знати, що ти (і я!) Робиш помилки.

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

Якщо ви не помилитесь, то, можливо, TDD для вас не так важливий, як для мене!

У мене є лише кілька зауважень:

1. Схоже , ви намагаєтеся перевірити всі . Ви, мабуть, не повинні, лише високий ризик та конкретні випадки певного коду / методу. Я впевнений, що тут застосовується правило 80/20: Ви витрачаєте 80% на написання тестів за останні 20% коду або випадків, які не охоплені.

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

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

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

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

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

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