Дизайн для теста ИЛИ Прекратить разработку для теста
Так что лучше. Начнем ли мы позволять тестам разрабатывать наш код. Мы начинаем внедрять конструктор для зависимостей только для того, чтобы сделать код тестируемым? или мы используем защищенный метод "переопределения" и подкласс тестируемого класса.
Аминь. Я спрашиваю себя об этом всякий раз, когда посвящаю время написанию автоматических тестов для существующего (или даже нового) кода. Кажется, ни один дизайн не подходит как для приложения, так и для тестов. Конечно, развязка - это хорошо, но тестирование вводит новое требование, требующее кардинальных изменений снизу вверх.
Оба подхода разумны в зависимости от контекста ...
Ответы 3
Я вообще считаю, что тестируемый код - это хороший код. Чтобы код можно было тестировать, вам нужна лучшая развязка, чтобы каждый компонент можно было тестировать изолированно с помощью тестовой оснастки. Однако в реализации не должно быть кода, который используется только модульными тестами.
Также имейте в виду, что вам нужно тестировать общедоступный API объекта, а не его защищенные / частные методы. Поиск ошибок в частном / защищенном методе должен быть тем, для чего нужны журналы / отладчики. В конце концов, ошибка в них также будет распространяться на общедоступные методы. Итак, пока общедоступные методы выполняют тесты, защищенные методы тоже будут охвачены.
Если вы используете java и у вас есть классы с областью действия пакета, которые реализуют общедоступные интерфейсы в одном пакете, я бы поместил модульные тесты в том же пакете в отдельную папку для тестирования этих классов. Вы также можете поместить модульные тесты в тот же пакет, что и тестируемый класс, для тестирования защищенных методов.
Я в основном согласен со Стейлом, хорошо разработанный код должен быть тестируемым. Я не использую инъекцию конструктора или производные классы для тестирования. Я считаю, что использование «локаторов сервисов» - правильный способ внедрения зависимостей.
Если ваши тесты хорошо спроектированы, они будут имитировать использование в реальном мире. Поэтому действительно хороший набор модульных тестов, которые охватывают все мыслимые способы использования вашего кода воля приложением, должен привести к надежной реализации. Если ваши тесты ошибочны, то вы не многого добьетесь.
Так что насчет внедрения конструктора для разъединения зависимостей.