Дизайн для теста ИЛИ Остановить проектирование для теста

Question

Так что лучше. Мы начинаем позволять Тестам разрабатывать наш код. Начнем ли мы вводить конструктор для зависимостей, чтобы сделать код тестируемым? или мы используем защищенный метод «переопределить» и подкласс тестируемого класса.

Answer 1

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

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

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

Answer 2

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

Answer 3

Я в основном согласен со Staale, хорошо разработанный код должен быть тестируемым.
Я не использую инъекцию конструктора или производные классы для тестирования. Я считаю, что использование «сервисных локаторов» - это правильный способ внедрения зависимостей.