Подготовка модульных тестов :Что важно иметь в виду при работе над архитектурой программного обеспечения?[закрыто]

Question

Допустим, я начинаю новый проект, качество которого является главным приоритетом.

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

Редактировать :Несколько раз назад я читал статью (сейчас я не могу ее найти), в которой говорилось о том, как отделение кода создания экземпляра от поведения классов может быть полезно при модульном тестировании.Именно такого рода советы по дизайну я ищу здесь.

Answer 1

Простота тестирования достигается за счет возможности заменить как можно больше зависимостей, которые имеет ваш метод, тестовым кодом (mocks, подделки и т.д.). В настоящее время рекомендуемый способ добиться этого - с помощью инверсии зависимостей, он же Голливудский принцип:"Не звоните нам, мы позвоним вам". Другими словами, ваш код должен "спрашивать о вещах, а не искать их".

Как только вы начнете думать таким образом, вы обнаружите, что код может легко зависеть от многих вещей.У вас есть зависимости не только от других объектов, но и от баз данных, файлов, переменных среды, API операционной системы, глобальных файлов, одиночных файлов и т.д.Придерживаясь хорошей архитектуры, вы минимизируете большинство этих зависимостей, предоставляя их через соответствующие уровни.Поэтому, когда приходит время для тестирования, вам не нужна рабочая база данных, полная тестовых данных, вы можете просто заменить объект data объектом mock data.

Это также означает, что вы должны тщательно отделить построение вашего объекта от выполнения вашего объекта.Оператор "new", помещенный в конструктор, генерирует зависимость, которую очень трудно заменить тестовым макетом.Лучше передавать эти зависимости через аргументы конструктора.

Кроме того, имейте в виду Закон Деметры.Не копайте объект глубже, чем на один слой, иначе вы создадите скрытые зависимости.Вызываю Флинстоунов.Вильма.аддЧайлд(камешки);означает, что то, что вы считали зависимостью от "Флинстоунов", на самом деле является зависимостью и от "Флинстоунов", и от "Вильмы".

Answer 2

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

Я рекомендую вам ознакомиться с ТВЕРДЫЙ принцип, чтобы вы могли написать более тестируемый код.

Answer 3

Возможно, вы также захотите ознакомиться с этими двумя вопросами SO:

• Внедрение модульного теста
• Какой должна Быть Единица Измерения

Answer 4

Несколько случайных мыслей:

• Определите свои интерфейсы: отделите функциональные модули друг от друга и решите, как они будут взаимодействовать друг с другом.Интерфейс - это “контракт” между разработчиками различных модулей.Затем, если ваши тесты работают с интерфейсами, вы гарантируете, что команды могут рассматривать модули друг друга как черные ящики и, следовательно, работать независимо.

• Сначала создайте и протестируйте хотя бы базовую функциональность пользовательского интерфейса. Как только ваш проект сможет “разговаривать” с вами, он сможет сказать вам, что работает, а что нет ...но только если это не врет тебе.(Бонус:если у ваших разработчиков нет другого выбора, кроме как использовать пользовательский интерфейс, вы быстро выявите любые недостатки в простоте использования и рабочем процессе, и т.д..)

• Тест на самом низком практическом уровне: чем больше вы уверены в том, что маленькие кусочки работают, тем легче будет объединить их в работающее целое.

• Напишите по крайней мере один тест для каждой функции, основанный на спецификациях, прежде чем приступить к написанию кода. В конце концов, именно эти функции являются причиной, по которой ваши клиенты будут покупать ваш продукт.Будьте уверены, что он предназначен для того, чтобы делать то, что он должен делать!

• Не будьте удовлетворены, когда он делает то, что должен делать;обеспечьте это не делает делай то, что это не предполагалось сделать! Загружайте в него неверные данные, используйте его нелогичным образом, отсоединяйте сетевой кабель во время передачи данных, запускайте его вместе с конфликтующими приложениями.Это сделают ваши клиенты.

Удачи вам!

Answer 5

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