I am pretty well finished with the Tester Tour of the example testing for the GitHub API. It shows, from the tester’s point of view, how the REST API testing framework works. This is part of my own GitHub project, RubyTest.
I’ll be grateful for any reviewers’ comments, which can be created as Issues on the RubyTest project itself (best, b/c records!), or can be emailed directly to me at firstname.lastname@example.org.
Everyone loves a good example in the documentation. Often, in the software world, the example is code.
But does that example code actually work? If it did work at some point in the past, does it still work?
The only way to know for sure is to run it!
Over at my GitHub project, RubyTest, I’m building a tester ‘tour’ of part of the project. Each ‘stop’ in the tour consists of a small test (code) and its output (a log).
Each time I do a build of the tour, the build procedure executes each test and captures its refreshed log. These are both plugged into a text file that becomes the markdown page for a tour stop.
So I always know that the test code still works!
Check it out:
A new stop on the GitHub API tester tour: CRUD. Shows how a data object offers convenience instance methods
Over at my GitHub project, RubyTest, I’ve added an example Changes Report.
This is the report that I rely on the most.
Check it out.
In testing web applications, the page object design pattern has become justifiably famous. Its job is classic data hiding: each such object encapsulates an HTML page.
When I began working on my first framework for testing a REST API, I asked myself how, if at all, this encapsulation principle applies there. And the immediately obvious answer is: the endpoint object.
Just as the page object encapsulates an HTML page, so does the endpoint object encapsulate a REST API endpoint. Each endpoint has its own encapsulating class.
Now an endpoint does not have a name, exactly, but it does have an HTTP method and a URL. I’ve used those to construct the endpoint class name.
Examples (from my framework for testing for GitHub’s own REST API):
|Method and URL
||Endpoint Class Name
|Get all labels.
|Create a label.
|Get the named label.
|Update the named label.
|Delete the named label.
A test framework should make things simple for the tester, right? To that end, the methods in these objects accept and return actual Ruby
Label objects, not raw JSON. The methods transparently handle the transforms between JSON and those objects.
Each endpoint has four such methods. Using
PatchLabels as an example:
PatchLabels.call(client, label) creates a label and returns the created label as a
PatchLabels.call_and_return_payload(client, label) does the same, but returns both the
Label object and the raw JSON payload (in case the caller want to examine it).
PatchLabels.verdict_call_and_verify_success(client, log, label) creates a label and returns the created label as a
Label object, also logging relevant verdicts.
PatchLabels.verdict_aberrant(client, log) accesses the endpoint with various error-causing aberrations, logging relevant verdicts, and returning nothing.
Voilà, the endpoint object!
I’ve added stops to the tester tour of the REST API test example.
It now includes endpoint testing for the GitHub API
The tour shows how a tester would use project
RubyTest to test the GitHub REST API.
Software Test Automation Professional / Zealot: resume.
I’ve decided that the next thing to add to RubyTest is the Changes Report.
This is the report that matters most to actual testers, because it filters out all the noise of unchanged test results, focusing instead on the most interesting results — those that are different from the previous result.
See more at the link above.
I have added a Future page to my GitHub project RubyTest.
It lists and briefly describes certain enhancements I can envision.
If you have an opinion about what you’d like to see, please open an Issue in the project, or Leave a comment (link below), and I’ll open the Issue.
In project RubyTest, added class Configuration, to support YAML configuration data.
– File inclusion.
– Returned hash key is Symbol, not String.
– Convenient syntax for expressing path into config data.