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

Question

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

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

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

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

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

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

Answer 1

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

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

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

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

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

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

Answer 2

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

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

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

Answer 3

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