Форум программистов «Весельчак У»
  *
Добро пожаловать, Гость. Пожалуйста, войдите или зарегистрируйтесь.
Вам не пришло письмо с кодом активации?

  • Рекомендуем проверить настройки временной зоны в вашем профиле (страница "Внешний вид форума", пункт "Часовой пояс:").
  • У нас больше нет рассылок. Если вам приходят письма от наших бывших рассылок mail.ru и subscribe.ru, то знайте, что это не мы рассылаем.
   Начало  
Наши сайты
Помощь Поиск Календарь Почта Войти Регистрация  
 
Страниц: [1]   Вниз
  Печать  
Автор Тема: Обязательны ли тесты в проекте?  (Прочитано 22776 раз)
0 Пользователей и 1 Гость смотрят эту тему.
RXL
Технический
Администратор

ru
Offline Offline
Пол: Мужской

WWW
« : 24-03-2016 13:14 » 

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

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

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

А что думаете вы?
Записан

... мы преодолеваем эту трудность без синтеза распределенных прототипов. (с) Жуков М.С.
Джон
просто
Администратор

de
Offline Offline
Пол: Мужской

« Ответ #1 : 24-03-2016 15:24 » 

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

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

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

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

Я вам что? Дурак? По выходным и праздникам на работе работать. По выходным и праздникам я работаю дома.
"Just because the language allows you to do something does not mean that it’s the correct thing to do." Trey Nash
"Physics is like sex: sure, it may give some practical results, but that's not why we do it." Richard P. Feynman
"All science is either physics or stamp collecting." Ernest Rutherford
"Wer will, findet Wege, wer nicht will, findet Gründe."
Вад
Команда клуба

ru
Offline Offline
Пол: Мужской

« Ответ #2 : 24-03-2016 21:03 » 

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

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

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

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

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

В целом, я за адекватность Улыбаюсь Где-то наверное, и TDD панацея, но я с такой областью пока не сталкивался.
« Последнее редактирование: 24-03-2016 21:10 от Вад » Записан
Dale
Блюзмен
Команда клуба

ru
Offline Offline
Пол: Мужской

WWW
« Ответ #3 : 25-03-2016 04:33 » new

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

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

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

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

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

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

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

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

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

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

Код:
y = 1/x

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

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

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

+

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

+

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

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

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

+

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

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

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

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

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

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

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

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

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

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

Ходить по воде и разрабатывать программное обеспечение по спецификациям очень просто, когда и то, и другое заморожено. - Edward V. Berard

Любые проблемы в информатике решаются добавлением еще одного уровня косвенности – кроме, разумеется, проблемы переизбытка уровней косвенности. — Дэвид Уилер.
Страниц: [1]   Вверх
  Печать  
 

Powered by SMF 1.1.21 | SMF © 2015, Simple Machines