Должны ли тесты быть в том же проекте, что и логика приложения?
Это зависит. В любом случае есть компромиссы.
Сохранение его в одном проекте требует дополнительной полосы пропускания для распространения вашего проекта, дополнительного времени сборки и увеличения занимаемой площади установки, а также облегчает ошибку при наличии производственной логики, которая зависит от тестового кода.
С другой стороны, ведение отдельных проектов может затруднить написание тестов с использованием частных методов / классов (в зависимости от языка программирования) и вызывает незначительные административные трудности, такие как создание новой среды разработки (например, когда новая разработчик присоединяется к проекту) сложнее.
Насколько эти различные затраты имеют значение, зависит от проекта, поэтому универсального ответа нет.
Должны ли я иметь тестовые классы для отражения моих логических классов или у меня должно быть только столько тестовых классов, сколько мне нужно?
номер
У вас должны быть тестовые классы, которые допускают хорошо продуманный тестовый код (то есть минимальное дублирование, четкое намерение и т. Д.).
Очевидное преимущество прямого зеркалирования логических классов в ваших тестовых классах состоит в том, что он позволяет легко находить тесты, соответствующие определенному куску кода. Существуют и другие способы решения этой проблемы без ограничения гибкости тестового кода. Обычно достаточно простых соглашений по именованию для тестовых модулей и классов.
Как мне назвать мои тестовые классы, методы и проекты (если они идут в разных проектах)
Вы должны назвать их так:
- каждый класс испытаний и метод испытаний имеют четкую цель, а
- так, чтобы кто-то, ищущий определенный тест (или тесты для определенного модуля), мог легко его найти.
Должны ли тестироваться частные, защищенные и внутренние методы или только те, которые являются общедоступными?
Часто непубличные методы должны быть проверены. Это зависит от того, получаете ли вы достаточно уверенности от простого тестирования общедоступного интерфейса, или от того, что модуль, который вы действительно хотите тестировать, не является общедоступным.
Следует ли разделить единичные и интеграционные тесты?
Это зависит от вашего выбора среды (ов) тестирования. Делайте то, что лучше всего работает с вашими средами тестирования и делает так, чтобы:
- и модульные, и интеграционные тесты, относящиеся к коду кода, легко найти,
- легко запустить только юнит-тесты,
- легко запустить только интеграционные тесты,
- Все тесты легко запустить.
Есть ли веская причина не иметь 100% тестовое покрытие?
Да, есть веская причина. Строго говоря, «100% тестовое покрытие» означает, что каждая возможная ситуация в вашем коде выполняется и тестируется. Это практически неосуществимо практически для любого проекта.
Если вы просто берете «100% тестовое покрытие», чтобы означать, что каждая строка исходного кода выполняется набором тестов в какой-то момент, то это хорошая цель, но иногда в неловких местах бывает всего пара строк это трудно достичь с помощью автоматизированных тестов. Если стоимость ручной проверки этой функциональности периодически меньше, чем стоимость прохождения искажений для достижения этих пяти последних строк, то это веская причина не иметь 100% покрытия линии.
Вместо простого правила о том, что у вас должно быть 100% покрытие линии, побуждайте ваших разработчиков обнаруживать любые пробелы в вашем тестировании и находить способы исправления этих пробелов, независимо от того, покрыто ли количество линий или "покрыто" Улучшается Другими словами, если вы измеряете покрытые линии, то вы улучшите покрытие линий - но на самом деле вы хотите улучшить качество. Так что не забывайте, что покрытие линий - это просто грубое приближение качества.