Checking the results of a Factory in a unit test

前端 未结 5 1214
-上瘾入骨i
-上瘾入骨i 2020-12-15 05:35

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 inte

相关标签:
5条回答
  • 2020-12-15 05:59

    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.

    0 讨论(0)
  • 2020-12-15 06:06

    @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.

    0 讨论(0)
  • 2020-12-15 06:09

    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:

    1. Return values of queries (non-void methods) are what you expect them to be.
    2. Side-effects of commands (void methods) modify the object itself as you expect them to.
    3. 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

    1. 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!
    2. 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.

    0 讨论(0)
  • 2020-12-15 06:11
    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 */
        }
    }
    
    0 讨论(0)
  • 2020-12-15 06:18

    Since I don't know how your factory method looks like, all I can advise right now is to

    1. Check to see the object is the correct concrete implementation you were looking for:

      IMyInterface fromFactory = factory.create(...);  
      Assert.assertTrue(fromFactory instanceof MyInterfaceImpl1);
      
    2. You can check if the factory setup the concrete instances with valid instance variables.

    0 讨论(0)
提交回复
热议问题