Strengths of Spring from the point of automatic test generation #759
denis-fokin
started this conversation in
Ideas
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Spring framework is not supported by our project to the extent it could be.
Let’s take a look at a very naïve Spring application. A database is plugged into a Web Service. What are important parts of such an application, how user sees it, how UnitTestBot sees it?
User Perspective
Web Service is represented by a Java or Kotlin class. The class is marked with an annotation that gives the Spring framework a hint how to treat the class in the Spring framework ecosystem. As a side-effect the user easily identifies the purpose of the class.
There are a couple of important spots we need to mention. They are related to the application configuration:
PropertySource
Configuration
The annotations allow to add property files to initialize values inside the application and specify configuration which is typically used to instantiate application environment.
From the point of the application we are discussing, the property files usually contain specific information about data sources configuration, JPA configuration and so on. Basically, all environment-specific data is stored in the property files, and the application is supposed to be environment-independent.
How UnitTestBot is seeing a Spring application
Currently, UnitTestBot is Spring annotation unaware. This is why UnitTestBot cannot reuse application configurations, properties and mocks even if they are already configured for other user’s tests.
UnitTestBot treats spring application as a set of Java classes and able to find some semi-static analysis suggestions (sometimes better than a static analyzer) or fixate the current implementation. This approach could be useful but ineffective.
Why the current UnitTestBot approach is ineffective for Spring applications
Where a lot of meta information that can be used in order to minimize the code that cannot be and should not be analyzed by UnitTestBot.
For instance, we should not try to analyze a class marked with SpringBootApplication, because usually it contains common application startup configuration. We hardly find any issues with the setup because UnitTestBot cannot verify it.
We should not try to cover classes with Configuration annotation because they only contain logic related to bean instantiation.
Entity classes are not good for analysis as well, because usually they are just a representation of database data.
Where we should focus
On the other hand, there are lot of places where we can apply UnitTestBot strengths.
RestController, Controller, RequestMapping and similar annotations are good clues if we are looking for the business logic of an application.
We should focus on testing the code that is connected with such classes. It would be an easy task if not the IoC concept.
Inversion of control (IoC)
IoC is a powerful feature of Spring but our engine is not aware about this routine. UnitTestBot can try synthesize data and fill autowired fields with such a synthetic objecta, but we can do better.
IoC assumes marking fields of Spring classes. Spring in turn initializes the fields with appropriate objects. Objects are found by their type. Good news that Spring application is usually contains data about the object (bean) initialization. Bad ones is that such initialization is associated with some tricky initialization of Spring instances like datasources and repositories.
What we can do
There are a couple of built-in annotations for mocking Spring applications, namely TestPropertySource
and TestConfiguration.
With the annotations we can try to
• generate test configurations and test property sources
• ask the user to generate such a configuration
• reuse a configuration that the user has already created for their own tests
We can use annotations like @SpringBootApplication to identify classes we should not analyze (we hardly find a problem there because them contain Spring specific configuration routines).
Finally, we can get more information from annotations like @entity and validators.
Conclusion
It is hard to make users add meta information to their code. Spring is an exception where developers use a lot of annotations. We usually try to find out such information on our own in order to use the information for fuzzing and naming. On the other hand Spring is a framework where we potentially can reuse testing environment.
Beta Was this translation helpful? Give feedback.
All reactions