Обязательны ли тесты в проекте?

[RXL]

Мне встречались совершенно разнополярные мнения по этому вопросу:

1. Тесты писать обязательно, лучше вообще TDD. Код без тестов некондиционный.
2. Тесты отнимают много времени. Программист высокой квалификации может писать чистый код.

На мой взгляд мнение 2 ошибочно:
* Человеку свойственно ошибаться.
* Нельзя быть уверенным, что чужой код тоже качественный и прозрачный и не сломается от внедрения в него.
* Никакая квалификация не защитит от опечатки: один символ в программе может изменить результат кардинально.
* Проявление ошибки отложено и может вылететь в готовом продукте.
* Перекладывание бремени поиска (возможно и исправления) ошибки на других разработчиков.

А что думаете вы?

[Джон]

Согласен, тесты требуют дополнительного времени времени, особенно для простых вещей (для сложных понятие времени относительно).

Но, (личное моё убежденение)
1. Тесты нужны, тесты важны и тд и тп (за компартию агитировать не собираюсь)
2. Самое главное (ИМХО) с тестами нельзя филонить: "тут играем, тут не играем, это пропускем" (с) Они 100% себя оправдывают (окупают и тд), если выполнены полноценно и постоянно актуализируются.
3. Тоже главное: не забывать делать тесты не только для благополучных сценариев, но и для ошибок.

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

К сожалению, у меня появляется возможность TDD только в C# проектах "с нуля".

[Вад]

Код коду рознь.

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

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

Если в командных проектах совместное владение кодом активно практикуется (особенно если и ревью кода в каком-то виде есть), то особой потребности в системе тестов может и не быть. Проекты на 3-5 человек и 3-6 месяцев у нас без сколько-нибудь заметного покрытия тестами как-то нормально обходились.
Более крупные проекты (измеряемые человекогодами, а то и десятками) - уже совсем другой разговор. Там совместное владение не спасает, а легаси-код становится довольно неприятной штукой. Написание тестов для легаси-кода (когда оно возможно) ощутимо помогает, хотя заставить себя бывает непросто: выгоды не всегда очевидны, по времени может и дороже обойдись, но психологически комфортнее в работе, когда можешь достоверно убедиться, что новые правки ничего старого не ломают. Писать в таких проектах тесты с самого начала, наверное, лучше всего.
Про проекты на 1-2 человек можно сказать то же, что про крупные: сходство в том, что, хоть и по другим причинам, может расти технический долг, плюс массив кода пухнет и выходит за пределы охвата одним человеком, с теми же ровно последствиями, что и для крупного проекта. И поэтому тесты тоже повышают комфортность (и, местами, эффективность) работы, ну и качество, само собой.

Есть ещё ниша "продуктово-исследовательских" проектов, где мне доводится сейчас обретаться, и там просто нереально поддерживать высокое качество кодовой базы, потому что код в среднем выбрасывается раньше, чем устанешь вносить в него правки: постоянно идёт поиск новых алгоритмов и решений (в моём случае речь о задачах обработки изображений и OCR). Сложность в том, что всё это плохо поддаётся покрытию тестами, да и баги несколько отличаются от таковых в бизнес-логике, проявляясь чаще некорректными выходными данными, а однозначно валидировать их практически никакой возможности нет, можно только попытаться сколько-то репрезентативный набор тестовых данных подставить и прогнать в целом, "на глазок" (хорошо, если можно сравнить с результатами других алгоритмов, как у меня было на одном проекте, когда оптимизировался-допиливался видеокодек).
На моей практике, тут модульными тестами удаётся покрыть только отдельные утилитирные вещи. Ну и когда делается низкоуровневая оптимизация алгоритма (скажем, на CUDA переписывается), то тестирование его на сходство/идентичность результатов с уже имеющимся - нормальная практика, но я бы не назвал это тестированием, это скорее безальтернативный метод разработки.

В целом, я за адекватность Где-то наверное, и TDD панацея, но я с такой областью пока не сталкивался.

[Dale]

1. Тесты писать обязательно, лучше вообще TDD.

IMHO это очень практично. Хотя лично я в данный момент отдаю предпочтение BDD и (в идеале) ATDD, но это детали.

Код без тестов некондиционный.

Не совсем так. Может быть, его писал гений и он идеален. А может, он вообще никуда не годится.

Точнее будет сказать: мы ничего не знаем о коде без тестов. Это как в случае с мартышками, которые развлекаются с клавиатурой: нельзя отрицать возможность, что одна из них напечатала "Войну и мир", но и всерьез рассчитывать на такой вариант тоже не следует.

2. Тесты отнимают много времени.

Это так и есть (недавно смотрел свою личную статистику на этот счет; получилось примерно 2:1, т.е. 2 строки тестового кода на 1 строку продукционного).

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

Программист высокой квалификации может писать чистый код.

Я давно вывел для себя эмпирическую формулу:

Код:

y = 1/x

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

И еще: чистый код != рабочий код. Порой усердие разработчика заставляет работать такой код, рядом с которым выгребная яма покажется чистым родником.

* Человеку свойственно ошибаться.

+

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

+

* Никакая квалификация не защитит от опечатки: один символ в программе может изменить результат кардинально.

+, особенно если язык позволяет подобные синтаксические вольности.

* Проявление ошибки отложено и может вылететь в готовом продукте.

+

* Перекладывание бремени поиска (возможно и исправления) ошибки на других разработчиков.

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

А что думаете вы?

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

Прежде всего я подразумеваю, что речь идет в основном об автоматизированных тестах, хотя явно об этом не было сказано. Ручное тестирование крайне трудоемко и подвержено ошибкам; кроме того, оно слишком скучно, поэтому от него будут отлынивать при первой возможности. Хотя ручных тестов нельзя избежать полностью, их нужно свести к самому минимуму. Лишь автоматизированные тесты можно запускать столько раз, сколько потребуется, без ущерба для проекта.

Польза от тестового набора не только в том, что с его помощью можно убедиться в работоспособности проекта в данный момент времени. Добавляя новый код к уже работающему, разработчик не может быть уверен на 100%, что при этом ни одна из прежних функций не нарушится, даже если новая работает успешно (разумеется, за исключением индюков из левой части графика y=1/x, но их вклад в проект все равно минимален). Регулярный перезапуск ранее пройденных тестов (так называемое регрессионное тестирование) позволяет убедиться, что проект действительно развивается, а не топчется на месте, когда работавшее еще вчера сегодня оказывается неработающим.

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

Еще один важный аспект тестирования: выяснить, как поведет себя система в необычных условиях. Что будет с вашим сервером после DOS-атаки? Когда на вашу систему поступит сетевой пакет с нарушенной структурой? Когда переполнится SD-карта памяти? Без тестов можно лишь промямлить: "я учел эту возможность в коде" или более честно пожать плечами: "а хрен его знает...".

Когда несколько лет назад у меня появился интерес к программированию микроконтроллеров, именно дефицит инструментов для TDD долго препятствовал этому. В их поиске я обошел многие форумы, в том числе и до Шелека добрался в итоге. К счастью, "процесс пошел".