java testable code with configuratios

Question

У меня есть обычное приложение vanila java. Он включает в себя файл доступа и конфигурационный файл, из которого он считывает все конфиги. Я использовал шаблон фабрики для создания экземпляра и создания всех классов процессоров и использования классов. У меня есть класс db, который обрабатывает все связанные с db функциональные возможности. Мне нужно передать имена таблиц db в dbutil и другие конфигурации для классов обработки. Я хочу знать лучший дизайн для передачи конфигураций различным классам моего приложения. какова должна быть стратегия проектирования для тестируемого кода?

Design стратегия - 1.Read конфигурационный файл в одном классе и создавать различные конфигурации объектов. - (? Используйте добытчиками или публичные конечные поля для доступа к конфигурации полей) объект DBCONFIG, объект обработки конфигурации 2.pass в конструкторах конфиг объекты - передать dbconfig в dbutil и обработать конфигурацию для обработки util.

Стратегия проектирования 2 - 1.строчный файл конфигурации в одном классе в публичных статических полях. 2. Поместите класс конфигурации в каждый класс, и каждый класс получит все необходимое от общедоступных полей этого класса.

Благодаря

Answer 1

Когда делают UnitTests протестировать небольшую часть кода в изоляции.

В частности, UnitTest никогда не касается внешних ресурсов, таких как файловые системы или базы данных. Эти ресурсы заменяются тестовыми манекенами с простым, быстрым и настраиваемым поведением. (см. Test Driven Development by Kent Beck)

Поэтому, когда вы разрабатываете приложение, следуйте правилам clean code и simple design. Тогда ваш вопрос станет устаревшим ...

Answer 2

Я лично склоняюсь к первому подходу, чтобы вы могли внимательно следить за principle of Dependency Inversion. Независимо от того, какой класс нуждается в информации из файлов конфигурации, в идеале не следует читать его самостоятельно (либо из файла конфигурации, либо из класса, имеющего всю информацию), а вместо этого передавая необходимые значения из другого класса, который его запускает. Таким образом, все эти классы, которые нуждаются в информации о конфигурации, будут тестироваться (изолированно), просто предоставив «тестовые» значения конфигурации в своих конструкторах.

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