Zero efforts stubbing for your integration tests in Java
What's that
Anystub wraps function calls and attempts to find a matching call that has already been made and recorded. Two things can then happen:
- If there is a matching call, Anystub will recover the result that is associated with call and return.
- If there is not a matching call and it is allowed to make the real call, Anystub will make the call, record the result and return it.
Recorded calls and corresponding results are stored in files called stub-files.
Out of box anyStub includes wrappers for org.apache.http.client.HttpClient from Apache
HttpClient 4.5.8
to stub http connections and some interfaces from javax.sql.* to stub DB-connections.
Why do you need it
- make your tests independent from external data sources
- test classes, subsystems or the whole app against real data
- zero efforts to collect test data
- make your tests autonomous and running at any isolated build server
anyStub provides simple API and requires minimum overhead code to get the benefits.
How to cook it
Out of box Anystub supports Apache HttpClient and javax.sql.DataSource to record and replay requests.
To use it you need to inject wrappers properly. For stubbing http connection use org.anystub.http.StubHttpClient. The main
class for stubbing database calls is org.anystub.jdbc.StubDataSource. In tests you will create real connections and wrap them with
provided implementations by passing them as a parameter in constructor.
Examples below demonstrate how to stub connections in spring-boot tests.
Once you stub the connections and run tests all calls begin to appear in a default-stub file src/test/resources/anystub/stub.yml
Sometimes, you need to split the calls by different stub-files. To do that you can utilize an annotation @AnystubId. You can apply it at class or method level in test files.
You can put it with your test class/test method to direct saving all calls under the annotation in a distinct file.
By default, the file has a name of the class or the method with .yml extention.
You will find the files in src/test/resources/anystub/. The annotation
has a parameter "filename" to
give the file a specific name. The extension will be added automatically.
- here is an example of how to cover Accessing Relational Data using JDBC with Spring application from spring-boot guides with integration tests.
- here is an example of how to stub http connections in tests Consuming a RESTful Web Service from spring-boot guides with integration tests.
AnyStub library is developed for spring-boot applications to stub external communication. In the examples you run the same full spring container. The only difference is a bean wrapped by class from anyStun library. If you run spring container in tests in a application with a configuration in .xml files you can also consider injecting the classes.
You can stub any call in your plain-java application. Here is an
example of how to create a wrapper for a method get() of plain java class.
Remember
- Stubbing inconsistent systems, unstable components and timely available resources is a good idea
- Stubbing low level objects which works behind several levels of abstractions helps to create resilient integration tests and increases coverage
- Split and reuse your stubs among tests wisely
- Change or mock behavior of your system less - Try to find suitable data to test all aspects
- You can populate and modify your stub-files to prove your system works
Become a chief
In examples above, the stub files were created as by default with RequestMode.rmNew attribute.
That means all calls will be assessed against the stub files.
In case of the call is found in the file the result will be recovered from file and the hit of the real
system will be procrastinated (or maybe omitted if not required).
Duplicates of the calls do not appear in the stub-file.
If AnyStub failed to find a call it will hit the target system, store the call id and
results in the stub and return the result to caller.
AnyStub provides few more modes to proceed calls:
RequestMode.rmNoneSending requests to a real system is forbidden. If request is not found in a stub-file then exception is thrown.RequestMode.rmTrackIf the stub file just created all requests are recorded in the stub file (even if duplicated exists). If the stub-file exists sending requests to a real system is forbidden. Calls are expected exactly in the same order as it was on a record phase. If next call doesn't match records in the stub-file the exception thrown.RequestMode.rmAllThe Stub file clear on the first call. All requests are sent to a real system and results written to the stub-file. Duplicates are possible.RequestMode.rmPassThroughall calls go directly to a real system.