Всем привет ребят, честно, я даже соскучился по всем =)
В общем вопрос, скорее похоливарить, поэтому во Флейме. Вечный вопрос "писать или не писать" мы не учитываем, а нужно собрать максимальное количество мнений о том, что такое 100% покрытие тестами. Как это понимать?
В сети на эту тему много заумных статей, и каждый лагерь тянет одеяло в свою сторону, но "в чем сила, брат?", кто прав? Те, кто говорит, что тестами нужно покрывать каждый метод каждого класса и все возможные ситуации связанные с этим методом (включая выбрасывание исключений, то есть реально все возможные ситуации), а кто-то говорит, что тестировать нужно только бизнес-процесс, и если он отрабатывает правильно, то никаких проблем - можно запускаться, ибо изменения в бизнес-процессе это создание новых сущностей, а не изменение старых, а значит нужно будет просто поправить существующий тест под новый бизнес-процесс и всё продолжит работать.

_____________
программирование - инструмент для решения конкретных задач, любая попытка спроектировать что-то универсальное приведет к провалу.©paul85
В любом случае тебе прийдётся пройти путь изобретения велосипеда, который прошли другие, только причиной твоего изобретения будет непонимание принципов работы велосипеда изобретённого другими людьми.©SlavaFr
jQuery это попытка использовать АН-225 для перевозки зубочистки

В голосовалке не стал тыкать, на словах скажу.
По опыту и мнению опытных людей, нах не нужно 100% покрытие. Только ключевые вещи. Иначе необоснованно много времени уходит на тесты.
Что именно включать в тесты, должно решаться индивидуально в каждом случае. Впрочем, если собственник компании готов платить херову тучу денег разработчикам за то, что они не создают новое и не устраняют существующие баги, а пишут тесты... То почему бы и нет? Хотя это и противоречит здравому смыслу.

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

_____________
* Хэлп по PHP
* Описалово по JavaScript
* Хэлп и СУБД для PostgreSQL

* Обучаю PHP, JS, вёрстке. Интерактивно и качественно. За разумные деньги.

* "накапливаю умение телепатии" (С) и "гуглю за ваш счет" (С)

Тестом кашу не испортишь))) Но моему опыту избыток тестов не на пользу, ибо при небольшом изменении логики придется править и тесты. А они как раз и нужны для фиксации состояния. Так что я придерживаюсь третьего пункта.

А вообще во всем нужно искать золотую середину.

_____________
Если вам недостаточно собственных заблуждений, можно расширить их мнениями экспертов.

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.

Все просто, если заказчику это нужно, то тебе это нужно. Заказчиком может быть дядя/тетя, который платит тебе денежку или ты сам, если это твой пет проект или твоя компания.

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

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

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

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

sergeiss
twin
chee
я прям по вам скучал =)
Осталось еще дождаться Игорь_Vasinsky, Invis1ble, FatCat, YVSIK и будет прям полный комплект старичков

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

_____________
программирование - инструмент для решения конкретных задач, любая попытка спроектировать что-то универсальное приведет к провалу.©paul85
В любом случае тебе прийдётся пройти путь изобретения велосипеда, который прошли другие, только причиной твоего изобретения будет непонимание принципов работы велосипеда изобретённого другими людьми.©SlavaFr
jQuery это попытка использовать АН-225 для перевозки зубочистки

Michael, прям как боженька сказанул, осталось добавить "делай правильно - будет правильно"




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