Когда дело доходит до тестирования приложений, одна из самых важных вещей, более важных, чем ваша инфраструктура или методология тестирования, заключается в написании тестируемого кода.
Если вы используете управляемый тестами подход к разработкевы, естественно, будете стремиться к написанию тестируемого кода, но вам все равно нужно сосредоточиться на том, чтобы предоставить себе надлежащие возможности.Цель состоит в том, чтобы иметь прозрачное приложение.
Вот некоторые вещи, на которых нужно сосредоточиться:
- Сосредоточение ваших методов на конкретной функции и обеспечение четких точек переключения междуодин метод и другой.
- Обеспечение достаточного самоанализа во внутреннем объекте объекта уровня без ненужной демонстрации слишком большого количества информации.
- Создание документов HTML, которые структурированы таким образом, чтобы более близко соответствоватьконтроллер и пространство модели, применяя согласованную терминологию и соглашения об именах.
Я всегда считал, что тестирование похоже на то, что делает фокусник.Маг дает понять, что они делают и каковы результаты, но сам процесс не обязательно объясняется.Это похоже на программное обеспечение, в котором вы хотите узнать результаты, но не должны интересоваться деталями реализации.
Типичная магическая процедура показывает вам все соответствующие детали, например, что на исполнителе надета шляпа, и чтошляпа пуста, что у них в рукаве ничего нет, что шляпа крепкая и очень мало весит, и тогда они будут как-то вытаскивать кролика из своей шляпы.
Лично я склонен опираться более сильно нанаписание надежных модульных тестов и поддержание тонкости контроллеров, меньше внимания на функциональных тестах.Функциональные тесты могут быть очень сложными, чтобы получить правильные результаты из-за невероятно большого количества состояний, в которых может находиться система при рендеринге страницы.Поскольку вы можете протестировать только небольшую их часть, вам нужно будет расставить приоритеты для ваших проверок.
Интеграционные тесты хорошо работают для зрелых приложений, которые хорошо определены и в которых стоимость дефекта очень высока, но в противном случае они могутсоздание значительно больше времени, чем строгое дисциплинированное и строгое применение контроля качества.Плохой интеграционный тест может дать вам ложное чувство безопасности и может фактически снизить качество приложения.
Если у вас есть специальный отдел контроля качества, который может сосредоточиться на создании и поддержке полного набора регрессионных тестов, тогда интеграционное тестированиеотличная вещь, чтобы иметь.Для среднего разработчика, однако, это приводит к огромному дублированию усилий и может серьезно снизить производительность.Как и во многих вещах, речь идет о компромиссах.