Чому в тесті Джоеля відсутня розробка тестових програм?

Я читав цей блог Джоела Спольського про 12 кроків, щоб краще кодувати . Відсутність тестово керованої розробки дійсно мене здивувало. Тому я хочу передати це питання гуру. Чи справді TDD не варте зусиль?

Тестова розробка була практично невідома до виходу книги Кента Бека у 2002 році, через два роки після того, як Джоел написав цю посаду. Тоді виникає питання, чому Джоел не оновив свій тест, чи якби TDD був більш відомий у 2000 році, чи включив би його до своїх критеріїв?

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

Джоел насправді вирішив це конкретно в кількох місцях.

Він пояснив, що тести речей не здатні наздогнати багато важливих питань, особливо суб'єктивних, таких як "чи смоктає користувальницький інтерфейс цього програмного забезпечення?" За його словами, надмірна залежність від автоматизованих тестів у Microsoft - це те, як ми закінчилися з Windows Vista.

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

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

Сам Joel Spolsky відповів на це питання ще у 2009 році :

Джоел: Йде дискусія з приводу тестового розвитку ... якщо у вас є одиничні тести на все, подібні речі ... багато людей пишуть мені, прочитавши Тест Джоела, щоб сказати: "У вас повинен бути 13-й Про те, що тут: Тестування модулів, 100% одиничні тести всього вашого коду. "

І це вражає мене, як те, що я трохи надто доктринерний про щось, що вам може не знадобитися. Мовляв, вся ідея спритного програмування полягає не в тому, щоб робити речі, перш ніж вони вам знадобляться, а в тому, щоб виправити їх на сторінку в міру необхідності. Я відчуваю, що автоматичне тестування всього, багато разів, просто не допоможе вам. Іншими словами, ви збираєтеся написати дуже багато одиничних тестів, щоб забезпечити той код, який насправді буде працювати, і ви обов'язково дізнаєтесь, чи він не працює [якщо ви цього не зробите пишіть тести], насправді все ще працює, ... я не знаю, я отримаю для цього таку полум’я, оскільки я не так добре це висловлюю. Але я відчуваю, що якби команда справді мала 100-відсоткове покриття кодом своїх одиничних тестів, виникло б декілька проблем. Один, вони витратили б дуже багато часу, пишучи одиничні тести, і вони не обов'язково змогли б заплатити за цей час покращеною якістю. Я маю на увазі, вони мали б кращу якість, і вони мали б можливість змінювати речі в своєму коді з впевненістю, що вони нічого не порушують, але це все.

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

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

Ніхто, крім Джоеля, не міг відповісти на це точно. Але ми можемо спробувати деякі причини / спостереження.

Перш за все, тест Джоела не відсутній

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

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

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