如何在@BeforeClass测试方法调用的静态方法中使用bean

Question

Let's suppose I have a test class A which extends from class B . This class A has one method with @BeforeClass annotation:

@BeforeClass
public static void setUp(){
    createFakeData();
}

The method createFakeData() is in class B and its function is to create an object in database.

In order to do that, I have a bean in class B :

@Autowired
private DummyObjectsFactory dummyObjectsFactory;

And the content of the method createFakeData() could be something like that which returns a FakeData object:

public FakeData createFakeData() throws Exception
{
    return dummyObjectsFactory.createFakeData();
}

The problem I'm facing is that the @BeforeClass method has to be static, that means that the createFakeData method has to be static too. But I cannot set that method to static because my bean dummyObjectsFactory will be always null .

How can I make my createFakeData method static avoiding my dummyObjectsFactory bean to be not null?

Answer 1

As far as I know, that is not permitted in JUnit. However you can do some things for arrange it.

First, you can use TestNG , which allows to do exactly what you want.

If that is not an option, instead of using @BefloreClass annotation, you can use @Before . The difference between both is that @BeforeClass executes the method before all the tests while @Before executes the method before each test. If you use @Before , I would annotate the class with @Transactional in order to delete the data saved in the database.

In the end, if you don't want to execute the method for each test, you can use @Before and flat the call:

@Before
public void init(){
    if(!fakeDataCalled){
        createFakeData();
        fakeDataCalled=true;
    }
}

Answer 2

I believe you want to annotate your test class (B) with @RunWith(SpringRunner.class) so that the autowiring happens correctly.

Take a look at section 15.4.4 in the Spring Reference . You can also just browse to that page and search for "RunWith"

Caveats:

1. I don't like static methods. They tend to make unit testing difficult.
2. I don't like extending tests to make other tests. I find it easier to make each test standalone and use composition for any shared functionality (ie make utility classes for shared test functionality that reside in the test source tree).
3. I don't like my unit tests depending on autowiring. I mock all the dependencies and inject them with either reflection or the @InjectMocks annotation.