Для одного я майже ніколи просто не сиджу там і пишу одиничні тести. Одиничні тести є засобом для досягнення мети, а не самоціллю. Вони є способом відповіді "чи робить цей код основною задачею, яку він повинен".
Наприклад, деякі люди напишуть функцію, а потім відкриють інтерактивну сесію, щоб перевірити її на кілька значень і переконатися, що вона працює:
def fact x
if x == 0
1
else
x * fact(x-1)
end
end
>> fact 10
=> 3628800
>> fact 7
=> 5040
Але тепер ви виявите помилку:
>> fact -1
SystemStackError: stack level too deep
from (irb):2:in `fact'
from (irb):5:in `fact'
from (irb):10
Отже, ви виправите це:
def fact x
if x < 0
raise "Can't take the factorial of a negative number"
elsif x == 0
1
else
x * fact(x-1)
end
end
>> fact -1
RuntimeError: Can't take the factorial of a negative number
from (irb):3:in `fact'
from (irb):10
Але тепер вам дійсно слід протестувати, щоб переконатися, що він все ще працює:
>> fact 10
=> 3628800
>> fact 7
=> 5040
Як бачите, ви продовжуєте повторювати ті ж самі тести ... і вам доведеться візуально порівнювати результати. Одиничне тестування - це спосіб уникнути повторення в цьому випадку; це зменшує кількість роботи, яку потрібно виконати. І хоча це маленький нерозумний приклад, в реальному світі він стає все більш важливим, і все складніше перевірити вручну. Звичайно, це означає, що люди просто не перевіряють окремі компоненти; вони просто перевіряють всю програму. Але тоді клопи обрізаються, і їх набагато складніше знайти. Або трапляються помилки, і вони виправляються, але хтось знову вводить ту саму помилку, оскільки ніхто не додав тестовий випадок, щоб переконатися, що цього не сталося. Або хтось дивиться на великий шматок коду і каже: "Я поняття не маю, що це робити, оскільки це не документально підтверджено і не має тестів ... якщо я виправляю цю помилку, я не маю уявлення, чи зламаю щось інше залежно від неї; можливо, я просто перепишу це з нуля ".
Експериментальні випробування зменшують всю додаткову роботу в цих випадках. Найкращий спосіб зробити їх веселими - переконатися, що люди розуміють всю роботу, яку вони замінюють, та додаткову гнучкість, яка випливає з того, що знає, що має робити кожен фрагмент коду. Певною мірою людям потрібно мати трохи більше досвіду написання та підтримки великої бази кодів, щоб зрозуміти, наскільки важливим може бути тестування одиниць; якщо весь їх код - це те, що вони пишуть один раз і викидають, вони його ніколи не отримають.
І одиничні тести не слід писати після факту, як додаткова робота, коли у вас є код, який ви "знаєте", вже працює. Експертні тести повинні бути складені спочатку або принаймні (оскільки іноді ви забудете їх написати) відразу після написання коду, про який йдеться. Це називається тестовою розробкою, і це може допомогти зробити ваші API краще; якщо ви спершу пишете тести, які виконують API, ви дізнаєтесь, де саме API застосовувати, перш ніж навіть написати код, і зможете переробити дизайн набагато простіше, ніж якщо ви лише потім додасте тести.
MbUnitБібліотека змінила моє життя. Автоматичне тестування є важливим. Автоматичне тестування економить час. Автоматичне тестування економить гроші. Автоматичне тестування може врятувати життя. Автоматичне тестування - єдиний спосіб. Автотестування є ще однією мережею безпеки. Коли я один із 50 людей, які працюють над величезною архітектурою, я відчуваю себе ще однією цеглою в стіні. З одиничними тестами я контролюю.