Skip to content

CT Unit Tests

kapilkalra04 edited this page Mar 23, 2018 · 8 revisions

NOTE: Either perform a JUnit + Mockito - based unit tests with no Spring auto-wiring or perform Spring integration tests with use of autowiring. Don't mix these two.

When we mix autowiring with test doubles from Mockito, autowiring wins and the code throws an exception.


Writing Unit Tests for BITS Darshini

As mentioned above, for writing unit tests for a class we resort to using JUnit and Mockito to carry out the required operations. So it's necessary to follow the below mentioned steps:

1. Check if the class for which you are creating tests needs any refactoring to be done.

Make use of @Data annotation as explained here. This will be useful when we create the test-class. Also Check if any class dependency hasn't been auto-wired. Autowiring helps us perform Dependecy Injection which is required to write an extensive Unit-Test. We use Field Autowiring, instead of Constructor or Setter Autowiring as Mockito has a restriction of creating Mocks for only either of the three and writing code for the latter two is very troublesome. To understand how to autowire dependencies/ understand what it is refer this

2. Writing a ConfigClass for your concerned class.

After you have Autowired your concerned class' dependencies, the concerned class receives them as Beans through the Spring IoC container or we explicitly provide them through a Config Class. To understand what beans are, refer this. As an example consider Class SaveRepository. So, now any beans that have to be provided to it explicitly are provided through its config class which will rightly be named as SaveRepositoryConfig. (Naming Conventioned followed - Add "Config" after the concerned class' Class Name").

As SaveRepository is present in /src/main/java/in/ac/bits/protocolanalyzer/persistence/repository package, the corresponding config class will also have a similiar path url. In the case of SaveRepositoryConfig it will be present inside /src/main/java/config/in/ac/bits/protocolanalyzer/persistence/repository package.

The final step is to use the @ComponentScan annotation in our concerned class' (SaveRepository) class-definition. Refer this so as to understand why it is done.

3. Adding the explicitly created beans in the Config Class to our Integration Tests Config Class.

As we provide our Concerned Class (SaveRepository) the beans it needs through its Config Class (SaveRepositoryConfig) at runtime, we need to simulate the same behavior for our Integeration Tests as well. What this means is that the Beans created in the SaveRepositoryConfig needed to added in the config class of our Integration Test(named: ExperimentTest) which is ExperimentTestConfig. So simply add all the bean creation code from ConcernedClassConfig to IntegrationTestConfig (SaveRepositoryConfig to ExperimentTestConfig)

NOTE: As of now we have only 1 Integration Test (ExperimentTest) , we do this only for its Config Class. If there are more Integration Tests in place, then we will have to repeat this step of copying bean declarions for the concerned class to all of the Integration Test Configs in existence.

Clone this wiki locally