Yet another reason to love REST
There are a lot of reasons why you should love REST. It’s fast, simple, stateless, and easy to debug. This makes it absolutely fantastic to test against.
REST APIs get you great end-to-end test coverage
Line for line, an end-to-end system test covers a lot more code than a deep down class-level unit test. They also more closely simulate a user’s actions, providing a realistic path of possible scenarios that need to be verified. So for the most bang for your buck, you want to be testing at the outermost level possible.
The ultimate level here is testing through UI automation — simulating clicks and looking for responses on screen, as a real user would do. However, although UI automation libraries are improving, UI tests still tend to be very complex to write and are often brittle to things like positioning/layout changes. A public API provides a fantastic alternative ‘hooking’ point of entry where application behaviour can be invoked from external code, without involving the UI but still typically mirroring fields and actions on screen pretty closely (if well-designed in order to keep your clients fast and lightweight).
So testing against an API avoids the complexity of UI testing but still give the system a thorough end-to-end workout.
Tests written against REST APIs aren’t brittle
Although the back-end behind your API may change considerably, a public API must continue to work in the exact same way or you’ll break all your clients and have a lot of very angry users. So as well as covering more lines of code for less effort, tests written against a public API won’t be as brittle and need updating as often as ‘subcutaneous’ ones testing against internal code structures.
Everyone can connect to a REST API
If you had to choose a protocol for interacting with your application, you couldn’t find a much simpler one than REST. Stateless HTTP, verbs, status codes and JSON — 99% of the time you need nothing but a browser to debug it, and your tests can be written in a completely different language than the API back-end and still be completely understandable.
Compare this to previous ‘standard’ HTTP protocols that were often anything-but understandable – even with things like service discovery and WSDLs (designed to help developers), debugging SOAP XML mismatches between a Java Metro client and a .NET WCF service is one personal hell I hope never to have to relive.
Not just for big APIs
Remember you don’t need a formal public API like Twitter or Facebook to realise the testing benefits mentioned here. Pretty much any sort of REST endpoint will do. The JSON handlers powering your single-page web app would be a great entry point to get started testing underlying behaviour, for example.
March 7, 2012- «Previous Post
- Next Post »
Leave Your Comment (Cancel Reply)
Your email will not be published or shared. Required fields are marked *
*
*
You may use these HTML tags and attributes: <a class="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>
