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

Question

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

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

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

Answer 1

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

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

Это также означает, что вы должны тщательно разбирать свою конструкцию объекта со своего объекта. «Новое» утверждение, размещенное в конструкторе, создает зависимость, которую очень сложно заменить тестовым макетом. Лучше передать эти зависимости через аргументы конструктора.

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

Answer 2

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

Я рекомендую вам ознакомиться с SOLID principle, чтобы вы могли написать более проверяемый код.

Answer 3

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

Answer 4

Вы также можете проверить эти два SO вопросы:

• Unit Test Adoption
• What Should Be A Unit

Answer 5

Некоторые случайные мысли:

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

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

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

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

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

Удачи вам!