TDD мертвий. Хай живе тестування

       
Від перекладача. Давид Хейнемейер Ханссон даною статтею підняв гостру тему обов'язковості використання TDD і, навіть, можливої ​​шкоди від написання тестів перед написанням коду. Саме ця стаття послужила лейтмотивом вже п'яти зустрічей на тему чи живий TDD , на яких Давид, Кент Бек і Мартін Фаулер обговорюють переваги і недоліки TDD, рамки застосовності й обмеження. Для тих у кого сприйняття усної англійської залишає бажати кращого, SergeyT публікує короткі саммарі у своєму G+ .
 
Фундаменталізм підходу «тести вперед» як статевий просвітництво, обмежене стриманістю: нереальна і неефективна повчальна кампанія повна ненависті до себе і сорому.
 
Спочатку все було по-іншому. Моє перше знайомство з TDD було схоже на люб'язне запрошення в кращий світ програмування. Змінити свідомість, щоб продовжити займатися практикою тестування там, де тестування раніше не було зовсім. Я побачив безтурботність добре протестованої кодової бази, і блаженство від почуття впевненості при внесенні змін в код.
 
Підхід «тести вперед» був чудовими підтримуючими коліщатками, він вчив мене, як думати про тестування на більш глибокому рівні, але досить швидко я відмовився від нього.
 
Через кілька років, риторика «тести вперед» стала голосніше і зліше. Більш підлої. І час від часу мене засмоктувало в воронку фундаменталізму, я відчував себе погано від того, що я не дотримуюся істинному писанню. У такі моменти я пробував практикувати «тести вперед» протягом декількох тижнів, тільки щоб кинути знову, коли моїм проектам ставало гірше.
 
Це був ефект маятника: гордість, коли я був в змозі дотримуватися букви вчення, і крах відчаю, коли не був. Це як починати пити після зав'язки. Замовчувати і не показуватися в суспільстві. На людях, я, в кращому випадку, говорив, що не завжди пишу тести перед написанням коду, а, в гіршому, продовжував підтримувати цей підхід як істинно вірний. Я шкодую про це зараз.
 
Може бути, було необхідно використовувати підхід «тести вперед», як таран для руйнування галузевого «шкода, у нас немає автоматизованого, регресійного тестування». Може бути, це була притча, яка не повинна була стати буквальним описом щоденного стилю програмування. Але як би це не замислювалося, незабаром все пішло не так. І тепер це використовується як молот, щоб збивати невіруючих, як лакмусовий папірець, щоб оголосити всіх інших непрофесіоналами і непридатними до програмування.
 
Досить. Вистачить. Мене звуть Давид, і я не пишу тести перед написанням коду. Я відмовляюся вибачатися за це і, тим більше, приховувати. Я вдячний за те, що TDD дав можливість побачити автоматизоване регресійне тестування у всій красі, але я давно пішов від догм цього підходу.
 
Я пропоную вам критично поглянути на те, як цей підхід впливає на цілісність вашого дизайну. Якщо ви готові чесно взяти до уваги можливість, що це не безумовно добре, то вибирайте червону таблетку. Вам може не сподобатися те, що ви побачите після.
 
Так куди ми йдемо?
 
Крок перший: необхідно визнати, що є проблема. Я думаю, що ми зробили це щойно. Другим кроком необхідно зрушити спектр тестування від модуля до системи. Нинішній фанатичний підхід до TDD робить основний упор на модульні тести, тому що, вважається, що вони здатні управляти дизайном коду (початкове обгрунтування підходу «тести вперед»).
 
Я не думаю, що це вірно. Підхід «тести вперед» призводить до надмірно складній структурі посередницьких об'єктів і манівців, так як необхідно уникнути «повільних» операцій Наприклад, звернень до бази даних. Або читання-запис файлу. Або запуску тестів в браузері, щоб перевірити всю систему. У результаті ми приходимо до створення монструозної архітектури. Густі зарості службових об'єктів, команд і щось гірше.
 
Я рідко пишу юніт-тести в традиційному сенсі цього слова, де всі залежності Мокан, і тисячі тестів можуть виконані за кілька секунд. Це просто не було хорошим способом тестування Rails додатків. Я тестую моделі Active Records безпосередньо, надаючи доступ до реальної базі даних. Тести працюють на рівні контролерів, але я б пішов далі і замінив би ці тести ще більш високорівневими тестами на Capybara .
 
Я думаю, що це той напрямок куди ми йдемо. Менше уваги на юніт-тести, тому що ми більше не використовуємо підхід «тести вперед» як проектну практику і більше увагу на повільні системні тести. (Які, до речі, зовсім не обов'язково повинні бути повільними, за рахунок використання розпаралелювання та хмарної інфраструктури).
 
Rails можуть допомогти з цим переходом. Сьогодні ми нічого не робимо, щоб заохочувати повні системні тести. У нас немає інструменту за замовчуванням в стек. Але ми збираємося виправити цей недолік. Але не чекайте, поки це станеться. Спробуйте Capybara вже сьогодні, і у вас буде гарне уявлення про те, де ми опинимося завтра.
 
Але спочатку зробіть глибокий вдих. Ми ведемо наших священних корів на забій прямо зараз. Це дуже болісно. Методологія TDD настільки успішна, що тепер вона вплетена в особистості великої кількості програмістів. TDD не тільки те, що вони роблять, це, хто вони. Ми проходимо депрограммірованія, щоб вийти з-під контролю TDD, і це займе деякий час.
 
Найгірше, що ми можемо зробити, це просто кинутися в іншу релігію тестування. Я легко можу собі уявити золотого тільця «тільки системні тести!» Будь ласка, не робіть так.
 
Так, для мене підхід «тести вперед» мертвий. Але замість того, щоб танцювати на його могилі, я віддам перевагу визнати величезний внесок TDD. TDD ознаменувала собою важливий етап у нашій історії, але прийшов час рухатися далі.
 
Хай живе тестування.
  
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.