Как проверить объект, когда я не могу получить доступ к состоянию?

Question

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

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

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

Я могу протестировать его в системе после того, как объект будет использован, но это приведет к большим испытаниям, которые сложно поддерживать.

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

Есть какие-нибудь мысли о других способах тестирования чего-то подобного?

Answer 1

Мне кажется, что вы пытаетесь слишком много проверить в рамках модульного теста.

Это признак того, что ваше подразделение пытается сделать слишком много.

Вы пытаетесь сделать три вещи здесь.

1. Получение данных со слоя доступа к данным.
2. Очистить данные.
3. Построить объект

Чтобы исправить, я бы переместил каждую из этих обязанностей в свои единицы (классы / методы), как вы предложили. Затем вы можете протестировать каждый модуль самостоятельно.

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

Answer 2

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

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

Правильно, вы меняете систему для тестирования.И это хорошо .Это пример Test Driven Design, демонстрирующий лучшую конструкцию, демонстрирующую более слабое сцепление и более высокую сплоченность, заставляя вас идти по пути предоставления вашим классам меньших обязанностей.(В идеале, каждый класс должен иметь только только одну ответственность .) Это одно из ключевых преимуществ TDD, поэтому не боритесь с этим.

Answer 3

Я знаю два способа добиться этого: - в Java, используя рефлексию.- (и самое лучшее, IMO) программирование ориентировано на интерфейсы, поэтому вы можете реализовать интерфейсы, с помощью которых вы можете получить доступ к данным.