Как вы сделали модульное тестирование более приятным? [закрыто]

Если вы всегда любили юнит-тестирование, хорошо для вас! Но для несчастных, которые не родились с пристрастием к этому, как вам удалось сделать эту задачу более приятной?

Это не вопрос «что такое правильный путь для модульного тестирования». Я просто хочу знать маленькие личные уловки, которые уменьшают скуку (смею сказать) написания юнит-тестов.

Во-первых, я согласен с вами - если вы пишете свои модульные тесты для уже завершенного кода или вы вручную тестируете свой код, я нахожу это чрезвычайно скучным.

Я считаю, что есть два способа модульного тестирования, которые действительно делают его приятным:

1. Используя Test Driven Development (TDD) - сначала написание тестов позволяет мне подумать о следующей функциональности или поведении, которые мне нужны в моем коде. Я нахожусь в движении к своей конечной цели маленькими шагами и вижу ощутимый прогресс в достижении этой цели каждые несколько минут чрезвычайно полезным и приятным.
2. Когда есть ошибки, вместо того, чтобы идти прямо к отладчику, это забавная задача - найти способ написать неудачный модульный тест, который воспроизводит ошибку. Чрезвычайно приятно наконец выяснить обстоятельства, которые делают ваш код неудачным, затем исправить его и посмотреть, как индикатор станет зеленым для нового неудачного теста (и останется зеленым для всех ваших существующих тестов).

Самодовольное превосходство.

Я только полушутя «Посмотрите на меня, вырабатывая хорошие привычки в программировании! Это« модульное тестирование »- это то, чего я с десяти лет назад никогда бы не сделал - какой дурак! И просто подумайте обо всех ошибках, которые я собираюсь обнаружить в результате эту скучную, утомительную работу, которую я делаю сейчас - мой код будет потрясающим! Я точно получу повышение! * "

* - Нет, я не буду.

Я нахожу это как тренировка или здоровое питание; до тех пор, пока не начнутся ощутимые выгоды («Святые шары, я действительно ЕСМЬ ловлю кучу ошибок регрессии, которые могли бы попасть в производство!»), моральная гордость от осознания того, что вы делаете Правильное, может помочь вам нести вас. через.

Во-первых, я почти никогда не сижу там и не пишу юнит-тесты. Модульные тесты - это средство для достижения цели, а не самоцель. Они являются способом ответа «выполняет ли этот код основную задачу, которую он должен».

Например, некоторые люди напишут функцию, а затем откроют интерактивный сеанс, чтобы проверить ее на нескольких значениях и убедиться, что она работает:

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 труднее всего использовать, прежде чем даже писать код, и его можно будет значительно проще перепроектировать, чем если бы вы только добавляли тесты позже.

Я не знаю. Что действительно делает модульное тестирование более приятным для меня, так это мысль о всех разочаровывающих, длительных, скучных и неуместных отладках, которые мне не придется проходить каждый раз, когда я изменяю программное обеспечение :)

Самодовольное превосходство, которое вы ощущаете, когда проверяете код, который является надежным, надежным и стабильным. И если вы пишете модульные тесты с помощью инструмента покрытия кода, вы можете похвастаться в своих комментариях проверки, что ваше покрытие кода составляет 90% или выше.

Очевидно, что удовлетворение от разработки в первую очередь вызывает удовлетворение, и вы испытываете чувство, когда ваш дизайн и тесты объединяются. Однако написание тестов для уже существующего / унаследованного кода может быть ошеломляющим и разочаровывающим. Когда наш проект находился в режиме обслуживания, я написал тесты для непроверенного кода, используя отчет о покрытии в качестве игры. Вы можете создать небольшую конкуренцию с собой и / или другими, чтобы увеличить количество покрытия. Конечно, вы можете зайти слишком далеко и создать плохие тесты, но это может быть хорошим мотиватором.

Попробуй попасть в Поток . Ставьте перед собой жесткие, но достижимые цели. Что может быть целью в модульном тестировании? Например, старайтесь писать быстрее, сохраняя качество. Модульные тесты не требуют слишком много размышлений, поэтому ошибиться вряд ли. Сконцентрируйтесь на своей цели и часто проверяйте, чтобы увидеть, как вы приближаетесь к ней.

Иногда, чтобы получить мотивацию, я записываю свой текущий «охват кода» в начале дня. Затем каждый раз, когда я пишу тест и выполняю его, я запускаю комплект и обновляю номер покрытия. Это весело, и это помогает напомнить мне, почему я делаю это. (Есть и другие причины, но мне нравятся цифры. Может быть, это только я!)

Не пытаясь обмануть себя, я могу заставить себя думать, что модульное тестирование может быть приятным в течение любого продолжительного периода времени.

Принятие реальности того, что юнит-тестирование не для того, чтобы им пользоваться, очень помогает мне, заставляя меня осознать, что я ищу что-то в месте, где его никогда не должно было быть.

На этих коротких ментальных экскурсиях, когда я дохожу до того, что воспринимаю юнит-тестирование, чтобы оно было тем, чем оно является на самом деле, то есть жестоко, невыносимо и душераздирающе скучно, я спрашиваю себя, могу ли я позволить себе отпустить их, т.е. высокие гарантии о функциональной правильности.

Неизбежно, ответ - громкое «нет».

Принимая мою судьбу, я продолжаю толкать эти квадратные объекты с буквами, цифрами и символами на них передо мной, которые мы называем клавиатурой, зная из первых рук, что при каждом нажатии на клавиатуру конец юнит-тестирования ближе, чем он была когда - либо был.