Запах кода в том, что специальный конструктор используется только во время тестирования?

Question

Предположим, у меня есть класс Foo, экземпляр которого создается только с экземпляром класса Bar:

public Foo(Bar x) {
    this.a = x.a();
    this.b = x.b();
    ...
}

Теперь я хотел бы протестировать Foo, предполагая, что создать экземпляр Bar с желаемым состоянием сложно. В качестве дополнительного ограничения поля a, b, ... объявлены как окончательные, поэтому установщики для этих полей недоступны.

Можно было бы создать дополнительный конструктор в Foo:

protected Foo(A a, B b, ...) {
    this.a = a;
    this.b = a;
    ...
}

Этот конструктор используется только во время тестирования, которое я объявил бы в комментарии к этому конструктору.

Вопрос: Это запах кода?

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

Answer 1

Mocking Bar, скорее всего, будет считаться лучшей практикой.Вы должны быть в состоянии создать MockBar, чтобы вы могли сделать

Foo foo = new Foo(new MockBar(a, b));

Answer 2

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

Answer 3

Hmmmmmm.

• Если проблема в том, что бары сложно / громоздко создавать, то упростите их создание.
• Почему у вас также нет конструктора, который имеет сколько угодно аргументов, взятых из объекта Bar? Похоже, это обертка или дао. Вы можете избежать вызовов с 20 или 30 аргументами, используя оболочку, но как ваши инициаторы собираются создать оболочку (без использования вызова с 20 или 30 аргументами для создание обёртки или использование 20-ти или 30-ти уровневой цепочки сеттеров "return this")?

Тем не менее, о каких видах испытаний вы говорите? Если проверяемая вещь - это отдельные методы, или проверяемая вещь - это целое приложение в наиболее производственной среде, которое мы можем получить, это серьезно влияет на то, что требуется для создания среды. для вещи, которая будет проверена. «По мере того, как мы можем получить продукт, как мы можем получить», в частности, вы не должны выполнять какой-либо код, цель которого просто состоит в том, чтобы сделать тест успешным. Это несколько меньше проблем в тестах, нацеленных на более мелкие отдельные части приложения. «Тестирование» не всегда то же самое, что «тестирование». Испытание рулевых рычагов для автомобилей означает что-то вроде проверки того, может ли он выдерживать крутящий момент, который, как он говорит, может воздействовать на олово. Вы не делаете то же самое при тестировании всей машины. Тестирование детали - это не то же самое, что тестирование всей сборки.