Во-первых, я почти никогда не сижу там и не пишу юнит-тесты. Модульные тесты - это средство для достижения цели, а не самоцель. Они являются способом ответа «выполняет ли этот код основную задачу, которую он должен».
Например, некоторые люди напишут функцию, а затем откроют интерактивный сеанс, чтобы проверить ее на нескольких значениях и убедиться, что она работает:
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 человек, работающих над огромной архитектурой, я чувствую себя еще одним кирпичиком в стене. С юнит-тестами я в контроле.