Почему тесты не пишут вместе с кодом?

Кто из форумчан имеет опыт разработки тестов? Поделитесь инфой насколько они полезны и когда …

Только что - заоптимизировал кусочек кода, который ввиду своей критичности покрыт by unit tests «по самое не балуйся». И вуаля - мне даже не надо гонять «ручками» какие то тесты на живых данных из prod / полновесных апликухах: есть определенная доля уверенности что ничего не сломается. Вот именно ради этого всё и делается.

Опять же мой изначальный комментарий был про оценку «крупности» конторы

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

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

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

состряпать пользовательское соглашение на продукт чтобы потом вас за этот кусок продукта не смогли привлечь

Зачем нужно что-то стряпать? Ты рассуждаешь чисто с галерной колокольни, типа сбыть продукт и забыть как страшный сон. И смотря на то, как часто ты повторяешь про ответственность, я понимаю, что тесты тебе нужны исключительно чтобы прикрыть свою жопу, если бизнес у заказчика не пойдёт, требования поменяются и т.п. А вот если бы ты был с заказчиком в доле и твой доход зависел от его дохода, то наверное так не рассуждал бы. Ещё раз для тех кто в танке: выгоднее выкатить наговняканый на коленке за 5 минут продукт без всяких тестов, и с 15-20% кастомеров напоровшихся на баги работать вручную через сапорт и сейлзов, чем пол-года писать тесты и вылизывать код по феншую. Это нахрен никому не упало. И да, ещё раз, маленькая контора это такая, которая физически может себе позволить эти 20% скидывать на сапорт.

PS: небольшое отступление. Помнится как небезызвестная Вероника Степанова бомбила на ютубе от того, что заказала в одной известной галере для себя сайт магазина. Они её мурыжили буквально пол-года, в итоге сделали «не то и не так» за херову тучу денег. Зато, я уверен, код красивый и всё покрыто тестами. Как по мне, это типичный образец взаимодействия с галерой. «К пуговицам претензии есть? Нету, пришиты намертво!» (с).

заоптимизировал кусочек кода, который ввиду своей критичности покрыт by unit tests «по самое не балуйся»

В реальной жизни обычно требуется «всё поменять» и твоё покрытие тестами идёт по бороде.

Почему я пишу тесты в отдельных проектах:

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

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

- Логика в тестах обычно не совпадает с логикой самого кода. Код говорит о том как выполнить какое-то действие, а тест - что конкретно мы ожидаем увидеть в ответ на какие-то переданные данные (и, опционально, почему и вообще зачем это проверять). То есть это вообще отдельные "бизнес-штуки".

- Тестировать маленькие кусочки хоть и нужно, но часто не достаточно. Если я поменял какую-то часть кода мне скорее важно знать не что конкретно эта часть нормально работает, а что весь проект не развалился (и то что внесенные изменения не ломают тест для конкретно этого куска или тест я переписал после правок мне никак не поможет). И если я это такие тесты постараюсь запихнуть рядом с кодом это будет ужасная невнятная лапша. А вот когда это отдельно лежит - и сами тесты логичны и целостны, и в коде этого всего не будет, что в итоге упрощает читаемость кода.

- Тесты обычно запускаются всякими там qa-шниками в дженкинсах. Им мои сотни тысяч строк индусской скриптолапши не нужны, им бы не запутаться в своих этих "процедурных" "assert'ах". Они точно не будут рады если им придется выискивать нужные блоки по всему проекту.

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

В реальной жизни обычно требуется «всё поменять» и твоё покрытие тестами идёт по бороде.

Ваша «реальность» очевидно очень далека от моей. Я прекрасно знаю что такое time-to-market, и всё что я делаю сегодня должно было быть сделано «ещё вчера» (другими словами - мы в постоянном цейтноте). То что Вам представляется (или Вами выставляется) как «потеря времени» реально ускоряет разработку. Возможно существенную роль играет то что мы пишем софт для себя, и продаём сервисы который этот софт предоставляет. И я себе не враг - я хочу чтобы оно работало и зарабатывало, в том числе в мой собственный кармашек, потому как наши премиальные очень сильно коррелируют с прибылью конторы.

ПыСы: «всё поменять». Моё (довольно мудрое, должен заметить) начальство как-то заявило что адекватная оценка рисков приходит к годам 30-35ти. И это тот момент когда желание «до основанья, а затем» уходит напрочь. Могу только Вам пожелать достигнуть этого «дзена».

адекватная оценка рисков приходит к годам 30-35ти

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

желание «до основанья, а затем»

При чём тут желание? Это требование, причём не моё, а рыночной ситуации в конкретный момент. Сегодня одно надо, завтра другое.

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

Возможно существенную роль играет то, что если клиент вам говорит, что из вашего конструктора Лего нужно собрать идеальный шар, то вы говорите что «это невозможно, но можно сделать некое подобие, но не идеальное». Иначе говоря вы переиспользуете код (и соответственно тесты) в угоду своему видению мира. Да, это позволяет собирать продукт быстро и качественно, но такой продукт не будет полностью соответствовать потребностям бизнеса.

Я ещё раз объясняю, что крупная контора с одной стороны зависит от качества продукта (по многим причинам), а с другой может себе позволить действовать по принципу «жри что дают» и конечный кастомер вынужден обтекать. Более мелкие конторы имеют то преимущество, что могут себе позволить меньшую надёжность, но зато ориентированность на конечного потребителя и подбирать за счёт этого тех кастомеров, которые не согласны жрать что дают в общей столовке. При этом такая контора всё равно работает с кастомерами индивидуально, поэтому нет проблемы что большой процент будет проходить через сапорт – они в любом случае так или иначе будут индивидуально сопровождаться.

Это просто разные бизнес-стратегии и не надо рассказывать что «тесты ускоряют разработку». Тесты ускоряют сборку кубиков.

с кодом цейтнот, а ты предлагаешь тратить время на тесты, может тебе ещё и документацию написать

Благодарю! Теперь стало понятнее.

Литературное программирование есть, даёшь тестуальное программирование!

с кодом цейтнот, а ты предлагаешь тратить время на тесты

Автоматические тесты. Да, безусловно. И не тратить, а экономить на этом время.

не надо рассказывать что «тесты ускоряют разработку».

Именно так.

Тесты ускоряют сборку кубиков.

Называйте это как угодно.

Мне вот не понятно как можно покрыть тестами даже отдельный алгоритм.

Все разобрался.
Понял, что мои тесты - API код, который использует иной API.
Например.
Имеется скажем API для использования метаданных.
Берем и разрабатываем алгоритмы, которые умеют проанализировать сторонние xml и выделить из них ту общую часть, которая используется для работы с объектами некоторого типа.
Далее другой алгоритм на основе полученных метаданных умеет правильно загрузить и сохранить эти объекты и работать с ними.
Проверено на *.doc, *.xslx, *.frx …, …, …
Чем не

ТЕСТ?  

Это и новое API, а заодно и тест ранее разработанного …

У меня так! ...

Как там у других все же интересно …

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

Кстати, вообще не обязательно. Очень часто просто взлетели на какой-то волне, или на «старых темах», или просто «рынок был такой все перло», новые направления бизнеса несут и новые риски. А риск-менеджмент был заточен только на предыдущую модель, либо его вообще не было. И состояние «сколотили херову тучу денег» - это просто промежуточное текущее состояние от шел к успеху до банкротства :) В моменте кажется что там риск менеджмент, потому «что куча денег и не может ведь», интуиция и так далее. А по факту я, например, видел кучу ситуаций, когда сегодня миллионер (шел годами) - а завтра банкрот.