Якщо говорити в повсякденному, практичному плані, я думаю, що це повністю залежить від контексту .
У великій середній команді, яка працює на високих / дуже високих стандартах (думаю, банківська справа, військові, великі масштаби, високий бюджет чи критичні для бізнесу системи), то я думаю, що чітка "налагодження" повинна бути "результатом тестування" , і вони чітко дуже різні речі . В ідеалі тестування призводить до налагодження (у режимі постановки), і у виробництві нам потрібно майже нуль.
Тестування є широким за обсягом, регулярним і дуже формалізованим - тоді як налагодження - це особливий процес, який трапляється періодично, коли виникає потреба виправити певний збій - що не очевидно і вимагає більш глибокого дослідження функціонування системи та результатів її отримання.
Тут, на мій погляд, тестування є чимось істотним, тоді як налагодження - це специфічний інструмент, необхідний лише тоді, коли дозвіл на помилку непрозорий.
Я цілком розумію очевидну корисність TDD для великих команд і / або систем, ніж просто не можу дозволити собі бути "баггі". Це також очевидно має багато сенсу для складних (часто "бек-енд") систем або якщо в коді висока частка складності порівняно з вихідною. Тоді "тестування" має реалістичний шанс повідомити, коли і чому трапляються збої. Системи, які виконують багато складних робіт і призводять до чітко вимірних результатів, як правило, легко перевіряються, тому тестування відрізняється від налагодження. У цих випадках тестування рішуче має на увазі процедуру, формалізовану методику підтвердження або не підтвердження відповідності очікувань та фактичного результату. Тестування відбувається постійно і час від часу інформує нас про необхідність налагодження.
Було б чудово, якби це була всюдисуща істина, я б хотів, якби мої графіки циклів розмежували чітко визначеним бінарним висновком (червоним, зеленим), але ...
У моєму випадку (що, правда, є особливим - працюючи на 98% соло на невеликих середніх розмірах, на основі недостатнього фінансування, на корпоративних адміністраторах, орієнтованих на дані), я просто не можу зрозуміти, як TDD могло мені допомогти. А точніше "налагодження" та "тестування" практично однакові.
В основному, хоча використання терміна "тестування" передбачає / тісно пов'язане з методологією TDD.
Я знаю, що це абсолютно, абсолютно un-Zeitgeist "ухиляюся від невіруючого, шунь, шун", відчайдушно нехолодно сказати. Але, думаючи про мій контекст, з практичним капелюхом я просто навіть не розпливчасто, в моїй найсміливішій уяві бачу, як TDD міг би допомогти мені отримати більше співвідношення ціни та якості для моїх клієнтів.
А точніше, я категорично не згоден із загальним припущенням, що "тестування" є формальним кодовим процесом.
Моє основне заперечення (застосовне в моєму конкретному * контексті *) полягає в тому, що ...
Якщо я не можу написати код, який працює надійно - то, як, на пекло, я повинен писати код, який надійно працює для тестування зазначеного імовірно субстандартного коду.
Для мене ніколи не бачив ні одного прикладу , ні аргумент , що (в моєму конкретному контексті) Захопленим мені досить , щоб навіть потрудилися думати про написання одного тесту , я міг би писати деякий сміховинно несуттєвий код тестування прямо зараз, може бути , «робить моє сховище повернення користувача сутність з ім'ям == X, коли я запитую це саме - і тільки - це? ", але, мабуть, більше корисності в мені написання цього потоку, можливо, Інтернет-це справді-просто-просто-чисто-нерозумно-мовний самовдоволення-дико-недостатньо поінформоване-кров кипляче-чорно-марно-марнотратне, але я просто відчуваю потребу тут зіграти захисника чорта. (Добре сподіваюся, що хтось покаже мені світло і перетворить мене, можливо, це в кінцевому підсумку дасть моїм клієнтам кращі співвідношення ціни і якості?).
Можливо, "налагодження" іноді те саме, що "тестування". Під цим я справді маю на увазі, що в своєму щоденному робочому житті я приділяю принаймні третину свого часу, граючи з локальною версією моєї системи в різних браузерах, відчайдушно пробуючи різні різні нерозумні речі, намагаючись зламати свою роботу, а потім розслідувати причини, чому це не вдалося, і виправити їх.
Я на 100% погоджуюся з очевидною корисністю в мантрі TDD "червоний / зелений / рефактор", але для мене (працюючи з низьким середнім бюджетом, соло-земля RIA Land) я б дуже полюбив когось, будь ласка, покажіть мені, як я міг можливо , логічно і життєво реалістично отримують будь-яку додаткову цінність від написання більше (так само, як потенційно недосконалий код тестування), ніж я фактично взаємодію з повним (і по суті єдиним) результатом моїх зусиль, які по суті пов'язані з реальною взаємодією людини.
Для мене, коли розробники говорять про "тестування", це, як правило, має на увазі TDD.
Я намагаюся кодувати так, ніби були тести, я думаю, що всі закономірності / практики та тенденції, на які заохочувала все це тестування, орієнтоване на тестування, є фантастичними і красивими, але для мене в моєму маленькому світі "тестування" - це не писати більше коду, його насправді тестування реального світу виводить його наближаючи реалістично, і це практично те саме, що налагодження, а точніше, активна зміна тут - це "налагодження", що є прямим результатом людського, вихідного орієнтованого не автоматизованого "тестування". Це на відміну від загальновизнаного погляду на "тестування" як на щось автоматизоване та формальне, а на "налагодження" - як на щось людське та спеціальне чи неструктуроване.
Якщо мета справді ціна / гроші, і ви робите веб-інтерактивні програми, то результат цього проекту - це веб-сторінки, і, по суті, те, як вони реагують на людський внесок - тому "тестування" найкраще досягається тестуванням ці веб-сторінки, через реальну взаємодію людини. Коли ця взаємодія призводить до несподіваних або небажаних результатів, тоді відбувається "налагодження". Налагодження також тісно пов'язане з ідеєю перевірки стану програми в режимі реального часу. Тестування, як правило, пов'язане з автоматизацією, яка, на мою думку, часто є прикрою асоціацією.
Якщо мета справді цінна для зусиль, а автоматизоване тестування є ефективним та дуже вигідним, а налагодження - це лише результат цього тестування, або погана заміна автоматизованого тестування, то чому це другий найбільш відвідуваний веб-сайт у світі (Facebook ) настільки часто пронизані сліпо очевидними (для користувачів, але явно не тестувальною командою та кодом тестування) помилками?
Можливо, це тому, що вони зосереджуються на заспокійливих зелених вогнях і забувають реально використовувати результати своєї роботи?
Чи занадто багато розробників думають, що тестування - це те, що ви робите з кодом, а налагодження - це те, що ви робите періодично з IDE, оскільки піктограма стає червоною, і ви не можете зрозуміти чому? Я думаю, що ці слова мають з ними сумнівні судження, які загалом затьмарюють практичну реальність того, на що слід зосередити увагу, щоб закрити прогалини між очікуванням та результатами.