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.
Added Principles page to RubyTest project.
In the GitHub project RubyTest, I’ve updated the example REST API tests with queries.
See, for example, method
test_get_albums (second method in file) in class AlbumsTest.
Over at my GitHub project RubyTest, I have added a full-blown example REST API test.
This is working code, with examples and unit testing (i.e. testing for RubyTest itself).
Check it out.
For a long time now, I’ve been working on automated testing for legacy software (or legacy features of evolving software).
It’s been an education.
The thing is, a new feature should be developed with a test-first strategy that uses assertions. And a failed assertion should be repaired immediately.
But for a legacy feature, automated testing will reveal a number of low-severity bugs that will not be fixed anytime soon. That’s why detailed logging and a detailed changes report are paramount.
So now I’ve founded a new GitHub project, RubyTest, that will make available, as working software, much of what I’ve learned.
The beginning is modest — just a logger, a few helpers, and their tests. (Yes, the framework itself gets thorough testing.)
Next, I think, will be a simple REST client example that uses the endpoints at JSONPlaceholder.com. This will be the opportunity to show how the framework will handle endpoints, data objects, and verdicts.
Much more to come.
I’ve updated my resume to include links to my GitHub project, RubyTest, about which more shortly.
I’m pitching myself not as a tester, but as a test automation specialist. That’s actually what I’ve mostly been doing in recent years.
Here are some principles I try to keep in mind.
||Make code easy to read: code is read more often than
|DRYness: Don’t Repeat Yourself
||Avoid redundant code and data.
|YAGNIty: You Ain’t Gonna Need It
||Don’t write code before it’s needed.
||Maximize use of existing packages and libraries. The line of code you don’t write is the line of code you never have to debug. — Steve Jobs
||Explicate everything, even when “unnecessary.” If it goes without saying, it would go better by saying it. — Tallyrand
||Keep everything clean and consistent: run static code
analysis; resolve all issues before committing.
|Failed Verdict Diagnostics
||Log data sufficient to diagnose a failed verdict.
||Detect test errors early, fail early, log useful information.
||Trust, but verify. Monitor documentation for changes (programatically, of course).
From the documentation for Ruby gem
Contracts let you clearly – even beautifully – express how your code behaves, and free you from writing tons of boilerplate, defensive code. You can think of contracts as
assert on steroids.
I wrote here about getting better by reviewing the literature from time to time. The literature I specifically mentioned was one of the programming language cookbooks.
Well, recently I reviewed the Ruby Cookbook (while my car was being serviced) and saw Recipe 10.16, about Contracts. The recipe had code for a Contracts module; I was delighted to find later that since the book’s publication date [2005 — but a new edition is in work!], the Contracts idea has been made into a Ruby gem: Contracts.
You’re gonna love this!