Microtesting is a new, developer-led and automated testing methodology which solves the problems posed by the increasing adoption of microservices and it’s just as useful in testing traditional monolithic applications.
Microtests are run after unit tests (but before integration tests) and they validate the interfaces between microservices, libraries and applications which depend on one another.
Microtests can be incorporated into the build process using Jenkins, for example. Being light-weight, microtests run very quickly and regularly (unlike full integration tests) and so developers are given fast feedback on whether their changes have broken any interfaces elsewhere in the system.
Full integration tests can then be run with the assurance that the contracts between the interfaces are valid.
What are the benefits of microtesting?
Microtesting enables geographically-dispersed, cross-team collaboration with fast, automated feedback before code gets deployed saving time and money.
Enterprise level testing is still the unsolved conundrum for development. Interoperability and reusability are the targets for modem coding, but the sheer physical constraints of timezones, geography and even language can slow down even the most agile organisation in the development phase, and if they don’t then mistakes hit hard in the later phases.
Everyone knows the statistics about the increasing cost of fixing a bug that’s found at design time versus in production code (and every stage in between).
Integration tests, even automated, are still too late in the process for discovering that a key API a new enterprise service is depending on works in a different way, or with a different calling signature or a different protocol.
Microtesting is the solution to getting the development across enterprise (and beyond the enterprise) right at the right time. It enables cross-team collaboration with fast automated feedback, even before code gets deployed.
Developers are already using unit testing to know what to build, or what they expect to build. Every time they run the tests they know whether the code they intended to build works, what they still need to build, and what they need to fix.
Microtesting takes this concept to a grander scale, but keeps it close to the coders. Services exchange details of what they need and what they will provide. For example if Mike’s service needs to ensure that Alice’s service can receive a request and return a list of meetings in JSON format, then this request needs to be done whilst he’s coding not in a large specification document that’s out of sync with everyone’s code the moment it is written.
Alice too needs to know that when she’s coding that she’s building the right service that Mike needs, and not have to wait for him to build his, or come back from holiday, or take a flight. She needs to know right in her development environment, and once she is done, she needs to let Mike know that her code passes his requirements. As soon as it’s done.
Microtesting is about bringing cross-service testing and development to where it’s needed most, on the developer’s PC. Tests run fast, and the deployment Go/No Go decision is crystal clear.