Let’s talk about higher level testing – acceptance and end-to-end. Such test suites interact with your application in the same way as ordinary user. Therefore, we require our tests to communicate with application at the same layer. In other words, we should use the same interface whether is it GUI, browser or REST endpoint.
Naturally, higher level test suites should consist of possibly few tests. As they are expensive to maintain, there is no rationale behind checking complex scenarios with them. That is what lower level tests are for (ideally unit tests).
So basically whole difficulty amounts to writing suitable client. If your application serves user’s requests with HTTP, we are almost home. In order to put application under test, we would just send a request, check the response (is it 200 OK? does it contain expected data?) and so on, depending on individual needs. There are many tools that help writing or debug HTTP-based applications. You will find list in the end of this entry.
With browser things are even simpler (are they?!). Testing frameworks and tools like Selenium or CasperJS allow to open browser windows, load given page and interact directly with DOM. For instant, one can fill form fields, click buttons, even drag’n’drop can be achieved. To verify correctness, one can check if expected page was loaded or certain element is visible. `However, this approach is not very helpful when HTML is complex and one can not simply find interesting DOM elements without writing long, awkward queries. This problem become particularly bothersome with the evolution of frontend frameworks like Angular or Vue JS. Developers now think in terms of components instead of HTML tags. So there is a space for another class of tools, specialised in querying components, like Protractor for Angular-based apps.
What about unusual interfaces, with no plug’n’play tools? Write your own clients. I had the opportunity to test PBX system with ability to make calls between users. Testing scenario is easy to write down and imagine:
Given: There is a user A with number 100
Given: There is a user B with number 200
When: User A dials 200
Then: User B’s phone rings
When: User B answers
Then: User A and User B are involved in a conversation
There is no tool to behave like phone. I had to write one. I know for sure that protocol used to communicate between phones and PBX is called SIP. It partially resembles HTTP, but it requires exchanging multiple messages to establish conversation. Example here. No need to go into details; protocol is too complicated to implement it from scratch. Fortunately, there is an open source library pjsip, that has it covered. Using its python bindings I was able to accomplish given task.
To sum up, if only you are able to write a client for your application, then you are able to automate tests for it.
HTTP testing/debugging tools:2