Pull to refresh

«Я не пишу юнит-тесты, потому что ...» — отговорки

TDD *
Translation
Original author: James Sugrue
Я глубоко верю в методику TDD (разработка через тестирование), так как видел на практике пользу от неё. Она выводит разработку ПО на новый уровень качества и зрелости, хотя она до сих пор не стала повсеместно распространённой. Когда наступает момент выбора между функциональностью, временем и качеством, всегда страдает именно качество. Мы обычно не хотим потратить больше времени на тестирование и не хотим идти на уступки в количестве выпускаемой функциональности. Если вы не планировали использовать методику TDD с самого начала проекта, то потом очень трудно перейти на неё.

Все мы слышали множество оправданий, почему кто-то не использует TDD, но нигде нет лучшей подборки оправданий, собранных в одном месте, чем в книге "Прагматическое юнит-тестирование на Java с помощью JUnit" из серии "Прагматическая книжная полка". Я прочитал эту книгу несколько лет назад и подумал, что ни один ответственный разработчик после прочтения этой книги не останется без чувства, что юнит-тестирование — это один из самых важных аспектов работы разработчика.

Самая тревожная отговорка, которую я слышал — это "мой код слишком сложно тестировать". Этому может быть два объяснения. Одно — это большая часть вашего кода рисует UI (пользовательский интерфейс), а автоматизирование UI-тестов слишком сложно. Я соглашусь, что автоматизация тестирования UI — дело сложное (хотя и возможное), но для автоматизации должно быть сделано всё, что возможно: подумайте о регрессионных тестах. Если у вас есть полностью автоматизированный набор тестов, включая UI, вы всегда можете вносить новые изменения в код, пребывая в полной уверенности, что вы ничего не сломали.

Второе объяснение, почему ваш код слишком сложно тестировать — ваш дизайн слишком запутанный. Возможно, логика и UI-код слишком тесно связаны, и эта зависимость осложнит вашу жизнь, если у вас нет автоматического UI-теста. Вот тут как раз юнит-тестирование помогает создать хороший дизайн. Использовать JUnit очень просто, поэтому если мне только удастся выделить отдельный слой с логикой и писать для него тесты, мне удастся автоматически протестировать всю логику, которую когда-либо будет использовать UI. Что? У вас нет доменной модели? Тогда используйте заглушки (mock objects) — существует множество библиотек для этого.

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

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

    Книга "Прагматическое юнит-тестирование" пропагандирует модель «плати по ходу дела», согласно которой следует писать юнит-тесты с самого начала, вместе с тем, как вы пишите код, и тогда у вас не будет этого нервного периода в конце, когда вы в спешке будете пытаться впихнуть все ваши юнит-тесты.

    Так или иначе, если вы не пишите тесты с самого начала, как вы тогда проверяете, что код работает так, как задумано? Вы запускаете его вручную? Не будет ли тогда разумным потратить немного времени от ручного тестирования на написание JUnit-теста? Ведь вам придётся запустить этот кусочек кода ещё не раз в течение разработки проекта.

    На самом деле вас ожидает гораздо больше разных временных потерь, если вы не пишите юнит-тестов. Вы потратите время на дебаггинг, пытаясь понять, почему что-то не работает. Или вам придётся рано или поздно подрефакторить ваш код, после чего вы обнаружите, что после рефакторинга ничего не работает. Если у вас есть написанные юнит-тесты, у вас есть основа для уверенности.
  • Запуск юнит-тестов занимает слишком много времени
    Признаю, тесты, которые используют внешние зависимости или работают с пользовательским интерфейсом, могут действительно долго работать. Но предполагается вообще-то, что у вас должно быть несколько уровней тестирования. Уровень юнит-тестов должен запускаться быстро. Также у вас может быть некий уровень интеграционных тестов, которые тоже должны запускаться без ощутимых временных потерь — просто запускайте их не так часто, например, каждую ночь. Но при этом не забывайте про юнит-тесты — они должны быть настолько быстрыми, чтобы стать естественной частью процесса разработки.
  • Это не моя работа — тестировать код
    Я не представляю, в каком состоянии разработчик должен находиться, чтобы решить, что он может просто кидать готовый код через стенку. Если бы название вашей специальности было «тупо Кодер», то может, эта отговорка ещё бы прокатила. Но ваша работа — разрабатывать работающее ПО, а значит, у вас должно быть какое-то основание заявлять, что ваш код — работающий. Если тестовый отдел считает непростым найти ошибку в вашем коде, это будет творить чудеса с вашей репутацией.
  • Я не могу протестировать код, потому что я точно не знаю, как он должен работать
    На это сложно реагировать без недоверия. Если вы точно не знаете, как должен работать код, как вы вообще могли начать его писать? Сперва нужно понять требования.


В этой книге перечислены и другие отговорки. но эти — основные. А какие отговорки слышали вы?

Tags: tddunit testunit testingunit testsюнит-тесты
Hubs: TDD
Total votes 72: ↑60 and ↓12 +48
Comments 225
Comments Comments 225

Popular right now