По сути, у нас есть три основных проекта, два из которых являются веб-сервисами, а другой - веб-приложением. В то время как я удовлетворен тем, что мы максимально покрываем наши веб-сервисы функциональными тестами (все три проекта имеют свои собственные модульные тесты), функциональные тесты для веб-приложения занимают много времени для реализации. Под многим я имею в виду два раза, а иногда и больше, время, которое требуется для реализации тестируемой функциональности с включенным модульным тестированием.
Политика менеджера заключается в тестировании каждой добавляемой нами функциональности, даже если это не критично для бизнеса (например, новый CRUD).
Я согласен с тестированием всех функциональных возможностей веб-сервисов, потому что тестировать их вручную сложно, а также эти тесты выполняются быстро и не требуют особых усилий для реализации.
Итак, в чем смысл тратить больше времени на написание функциональных тестов, чем на написание системного кода, модульных тестов и исправлений тестов QA? Это нормально? Разве мы не должны писать функциональные тесты только для критической функциональности и позволять QA проводить регрессионные тесты без критической функциональности?
Примечание: мы не разрабатываем медицинское программное обеспечение или программное обеспечение НАСА или что-либо столь критическое.
источник
Ответы:
Функциональные тесты очень важны. Да, им нужно время, чтобы написать, но если вы пишете правильные функциональные тесты, они того стоят.
Есть несколько веских причин для проведения автоматических функциональных тестов в приложении.
В конце концов, да, для написания этих дел требуется время, но вы должны гордиться их написанием. Это ваш способ доказательства, без тени сомнения, что ваш код работает и работает со всеми остальными функциями. Когда QA приходит к вам и говорит, что есть ошибка, вы исправляете ее, а затем добавляете в свой набор тестов, чтобы показать, что она исправлена, и убедиться, что она больше никогда не повторится.
Это ваша сеть безопасности. Когда кто-то заходит и захватывает сохраненный процесс и вносит небольшие изменения, чтобы он работал со своим кодом, вы поймете, что он нарушил 3 других функции в процессе. Вы поймете это в ту ночь, а не в ночь перед крайним сроком!
Что касается написания функциональных тестов только для критических функций системы. Это не даст вам полную картину, и это позволит ошибкам проникать. Все, что нужно, это добавить одну маленькую функцию, которая не критична для системы, но косвенно взаимодействует с критичной для системы функцией, и у вас есть потенциальная возможность появления ошибки.
источник
Более чем в 2 раза ... мне кажется, немного много. Возможно, вы захотите проанализировать причины этого, они могут включать в себя:
плохая инструментальная поддержка для создания и сопровождения тестов
Контракты веб-сервисов недостаточно описаны в дизайне. Разработчики должны разрабатывать контракты во время тестирования, которое обычно занимает много времени.
Поговорите со своими разработчиками.
Предполагая, что вы разрабатываете в спринтах, эти функциональные тесты являются лишь частью спринта. Без этих тестов не обойтись. Если у вас его нет, ваше время на интеграционное тестирование после фазы разработки может удвоиться.
источник
Нормально ли тратить больше времени на внедрение функционального тестирования, чем на внедрение самой системы?
Абсолютно. Написание действительно хороших тестов, вероятно, займет большую часть времени во многих (хороших) магазинах.
Так что соотношение 2-1 хорошо. Сами менее опытные разработчики часто не принимают во внимание все тесты.
источник
Существует закон убывающей отдачи. Предполагая, что вы сначала пишете тесты для самого опасного кода, значение, сгенерированное последующими тестами, со временем уменьшается.
Модульные тесты - это код, поэтому они будут содержать ошибки (как и любой другой код). Исправление этих ошибок занимает время.
По моему опыту, юнит-тесты содержат гораздо больше ошибок, чем система, которую они тестируют, и их исправление - постоянное бремя.
источник
Это о качестве.
Если вам нужно выйти на рынок - вы разработаете свое приложение как можно быстрее. У вас даже не может быть автоматических тестов =), но вы отдадите свое приложение аудитории раньше, чем ваши конкуренты.
Но если вы знаете, что ваш слух не уйдет, вы сделаете все, что сможете, чтобы не разочаровать их. Каждый жук билета повредит вашей репутации. Представьте, что одна ошибка удалит 50 процентов вашей репутации, а другая - еще 25 процентов и так далее. Так может ли быть слишком много тестов?
источник
Если по «это нормально» вы спрашиваете, распространено ли это, нет, конечно, нет. Многие команды разработчиков имеют плохую практику тестирования (я принадлежу к одной) и даже качественные книги, которые я прочитал, советуют тратить примерно столько же времени на кодирование функциональности, чем тесты. Если по нормальному вопросу вы спрашиваете, здоров ли он, это зависит, но лучше в два раза больше тестов, чем нужно.
Это не должно быть критическим . Когда вы тестируете функциональность, вы тестируете что-то полезное для конечных пользователей, и вы обязаны знать (и не догадываться), что все время работает правильно. Если вам нужно в два раза больше для этой цели, то это должно быть сделано именно так - если это возможно.
Также возможно, что ваша политика слишком строга в отношении автоматизированных тестов, но трудно сказать, не зная, к какому качеству они стремятся, их ресурсам и к чему еще они могут быть привязаны.
источник