问题
I have developed some classes with similar behavior, they all implement the same interface. I implemented a factory that creates the appropriate object and returns the interface. I am writing a unit test for the factory. All you get back is an interface to the object. What is the best way to test that the factory has worked correctly?
I would like to know the answer in Java, but if there is a solution that crosses languages I would like to know it.
Number 2. in the answer, would be done like the other answer? If so I will mark the other answer accepted as well and reword my question to adress both a factory where an interface is returned and you have no clue what type of concrete class implemented the interface, and the case where you do know what concrete class was used.
回答1:
Since I don't know how your factory method looks like, all I can advise right now is to
Check to see the object is the correct concrete implementation you were looking for:
IMyInterface fromFactory = factory.create(...); Assert.assertTrue(fromFactory instanceof MyInterfaceImpl1);You can check if the factory setup the concrete instances with valid instance variables.
回答2:
What you are trying to do is not Unit Testing
If you test whether or not the returned objects are instances of specific concrete classes, you aren't unit testing. You are integration testing. While integration testing is important, it is not the same thing.
In unit testing, you only need to test the object itself. If you assert on the concrete type of the abstract objects returned, you are testing over the implementation of the returned object.
Unit Testing on Objects in general
When unit testing, there are four things, you want to assert:
- Return values of queries (non-void methods) are what you expect them to be.
- Side-effects of commands (void methods) modify the object itself as you expect them to.
- Commands send to other objects are received (This is usually done using mocks).
Furthermore, you only want to test what could be observed from an object instance, i.e. the public interface. Otherwise, you tie yourself to a specific set of implementation details. This would require you to change your tests when those details change.
Unit Testing Factories
Unit testing on Factories is really uninteresting, because you are not interested in the behavior of the returned objects of queries. That behavior is (hopefully) tested elswhere, presumable while unit testing that object itself. You are only really interested in whether or not the returned object has the correct type, which is guaranteed if your program compiles.
As Factories do not change over time (because then they would be "Builders", which is another pattern), there are no commands to test.
Factories are responsible for instantiating objects, so they should not depend on other factories to do this for them. They might depend on a Builder, but even so, we are not supposed to test the Builder's correctness, only whether or not the Builder receives the message.
This means that all you have to test on Factories is whether or not they send the messages to the objects on which they depend. If you use Dependency Injection, this is almost trivial. Just mock the dependencies in your unit tests, and verify that they receive the messages.
Summary of Unit Testing Factories
- Do not test the behavior nor the implementation details of the returned objects! Your Factory is not responsible for the implementation of the object instances!
- Test whether or not the commands sent to dependencies are received.
That's it. If there are no dependencies, there is nothing to test. Except maybe to assert that the returned object isn't a null reference.
Integration Testing Factories
If you have a requirement that the returned abstract object type is an instance of a specific concrete type, then this falls under integration testing.
Others here have already answered how to do this using the instanceof operator.
回答3:
@cem-catikkas I think it would be more correct to compare the getClass().getName() values. In the case that MyInterfaceImpl1 class is subclassed your test could be broken, as the subclass is instanceof MyInterfaceImpl1. I would rewrite as follow:
IMyInterface fromFactory = factory.create(...);
Assert.assertEquals(fromFactory.getClass().getName(), MyInterfaceImpl1.class.getName());
If you think this could fail in some way (I can't imagine), make the two verifications.
回答4:
if (myNewObject instanceof CorrectClass)
{
/* pass test */
}
update:
Don't know why this got marked down, so I'll expand it a bit...
public void doTest()
{
MyInterface inst = MyFactory.createAppropriateObject();
if (! inst instanceof ExpectedConcreteClass)
{
/* FAIL */
}
}
回答5:
If your Factory returns a concrete instance you can use the @Parameters annotation in order to obtain a more flexible automatic unit test.
package it.sorintlab.pxrm.proposition.model.factory.task;
import org.junit.Test;
import java.util.Arrays;
import java.util.Collection;
import org.junit.runner.RunWith;
import org.junit.runners.Parameterized;
import org.junit.runners.Parameterized.Parameters;
import static org.junit.Assert.*;
@RunWith(Parameterized.class)
public class TaskFactoryTest {
@Parameters
public static Collection<Object[]> data() {
return Arrays.asList(new Object[][] {
{ "sas:wp|repe" , WorkPackageAvailabilityFactory.class},
{ "sas:wp|people", WorkPackagePeopleFactory.class},
{ "edu:wp|course", WorkPackageCourseFactory.class},
{ "edu:wp|module", WorkPackageModuleFactory.class},
{ "else", AttachmentTaskDetailFactory.class}
});
}
private String fInput;
private Class<? extends TaskFactory> fExpected;
public TaskFactoryTest(String input, Class<? extends TaskFactory> expected) {
this.fInput = input;
this.fExpected = expected;
}
@Test
public void getFactory() {
assertEquals(fExpected, TaskFactory.getFactory(fInput).getClass());
}
}
This example is made using Junit4. You can notice that with only one line of code you can test all the result of your Factory method.
来源：https://stackoverflow.com/questions/37310/checking-the-results-of-a-factory-in-a-unit-test