Фабричные методы модульного тестирования, которые имеют конкретный класс в качестве возвращаемого типа

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

Существует тонкая грань между кодом, специфичным для тестов, и проектированием через тестирование. Мы не должны вводить код, у которого нет другого потенциала, кроме удовлетворения требований тестирования, но совершенно нормально вводить новый код, который следует общепринятым принципам проектирования. Мы позволяем тестированию управлять нашим дизайном — вот почему мы называем его TDD :)

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

Кроме того, я ответил второму надеру :)

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

Этот стиль тестирования просто гарантирует, что при внесении изменений в будущем поведение вашей фабрики не изменится без вашего ведома.

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

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

new Составляя все ваши типы по мере необходимости, вы не даете себе много швов (шов - это место, где вы можете изменить поведение в своей программе без редактирования в этом месте) для работы.

Однако в приведенном вами примере вы можете получить класс из фабрики. Затем переопределите / смоделируйте CreateADependency(), CreateAnotherDependency() и CreateAThirdDependency(). Теперь, когда вы вызываете CreateSomeClassWithDependencies(), вы можете чувствовать, были ли созданы правильные зависимости.

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

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

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

Глядя на ваш пример кода, да, Assert not null кажется избыточным, в зависимости от того, как вы спроектировали свою фабрику, некоторые будут возвращать нулевые объекты из фабрики, а не исключать.

Насколько я понимаю, вы хотите проверить правильность построения зависимостей и их передачи в новый экземпляр?

Если бы я не мог использовать такую ​​​​инфраструктуру, как google guice, я бы, вероятно, сделал что-то вроде этого (здесь с использованием JMock и Hamcrest):

@Test
public void CreateSomeClassWithDependencies()
{
    dependencyFactory = context.mock(DependencyFactory.class);
    classAFactory = context.mock(ClassAFactory.class);

    myDependency0 = context.mock(MyDependency0.class);
    myDependency1 = context.mock(MyDependency1.class);
    myDependency2 = context.mock(MyDependency2.class);
    myClassA = context.mock(ClassA.class);

    context.checking(new Expectations(){{
       oneOf(dependencyFactory).createDependency0(); will(returnValue(myDependency0));
       oneOf(dependencyFactory).createDependency1(); will(returnValue(myDependency1));
       oneOf(dependencyFactory).createDependency2(); will(returnValue(myDependency2));

       oneOf(classAFactory).createClassA(myDependency0, myDependency1, myDependency2);
       will(returnValue(myClassA));
    }});

    builder = new ClassABuilder(dependencyFactory, classAFactory);

    assertThat(builder.make(), equalTo(myClassA));
}

(если вы не можете имитировать ClassA, вы можете назначить не-фиктивную версию myClassA, используя new)