Many testers these days will find themselves in Rails shops and, even if that’s not the case, Rails is a good environment within which to build custom test solutions that require a database and a web interface. This is largely because when using Rails, you are using one of the most concise and expressive languages out there: Ruby. I plan to document some of my learning of the Rails ecosystem in two posts.
Author: Jeff Nyman
Anything I put here is an approximation of the truth. You're getting a particular view of myself ... and it's the view I'm choosing to present to you. If you've never met me before in person, please realize I'm not the same in person as I am in writing. That's because I can only put part of myself down into words.
If you have met me before in person then I'd ask you to consider that the view you've formed that way and the view you come to by reading what I say here may, in fact, both be true. I'd advise that you not automatically discard either viewpoint when they conflict or accept either as truth when they agree.
The Craft of Testing
Being a tester with an avid interest (and some practice) in fiction writing, I liken the craft of testing to the craft of writing fiction particularly because I found some correlations in terms of writing fiction and writing tests. (Oh, the opportunities for a few jokes there.) The focus I’m going to be building on here is really a similarity of craft or, more accurately, how there are similar thinking styles that translate between crafts.
Learning the Rails Way – A Tester’s Perspective
In a previous post I talked about learning Rails in a way that I wished it had been presented to me. Here I’ll focus a little on the salient facts about the framework that you will no doubt find elsewhere, but sometimes you have to distill it from surrounding material that gets in the way. Near the end, I’ll explain why any of this has relevance to me writing as a tester.
Continue reading Learning the Rails Way – A Tester’s Perspective
A Tester Learns Rails
I played around with Node.js in a previous post for web framework design. Now I want to explore Rails a bit. I haven’t found tutorials that I really like on Rails, at least for those getting started. Now that I have gotten started, some of those tutorials I did find are more helpful to me, but they weren’t as helpful starting out. So here I’ll write in a way that helped me learn more about how Rails is actually working, rather than just relying on the “magic” that everyone tells me is happening behind the scenes.
The Dialect Diary — Symbiont Reborn!
I have spent the better part of the last five years learning how to design effective and efficient test frameworks and libraries. I may actually be making progress. This post will detail a bit of why and show how the Dialect project has evolved into a radically new life form, albeit one that did exist before.
A Tester Learns Node.js
This is essentially a follow-on from my previous post on Node, mainly for the purposes of helping testers like myself figure out if it’s worth spending time on.
Why Test Engineers Should Learn Node.js
Lately I’ve found myself wanting to develop test solutions that essentially require a simple web server along with a lot of client-side logic. For example, a Gherkin repository interface is something I’ve been longing to do. I don’t want to learn Pylons (in the Python world) right now and while my focus is Ruby, I’m not too keen on the overhead and bloat of Rails. I’ve done a Sinatra app (Dialogic). Sinatra is sort of Rails-lite, but that doesn’t really help me with an optimized solution that is going to use a lot of JavaScript. Thus did I come across Node.js.
Post Job Opportunities That Attract Talent
Earlier I talked about the opportunity descriptions that I would like to see. Having these done poorly is a huge pet peeve of mine. Some of this is just the fact that companies go through recruiters. There are many, many good recruiters out there but, quite frankly, there are many others that simply don’t know how to get what clients need — and quite, frankly, some of the clients don’t seem all that in tune with it either. This post presents a case in point.
The Dialect Diary – Element Definitions
Dialect needs to support the idea of element definitions. Like assertion definitions, this is part of the generator concept, where methods are generated as part of Dialect’s operation. This is a core part of Dialect’s design that has to be as right as possible since pretty much everything else will flow from this.
The Dialect Diary – Assertion Generators
As part of Dialect’s operation, I want page and activity definitions to be able to assert aspects of themselves. This is different from the “assertion” you might be used to in terms of testing logic. This post will cover what assertion definitions mean and get into one of the key design elements of Dialect: the generator.
The Dialect Diary – Evaluators
Dialect supports the idea of evaluator methods. These will admittedly be some low-hanging fruit in terms of framework development, but they seemed like a good place to start. This post explains a bit about what an “evaluator” means and how they are used.
The Dialect Diary – Platform Objects
Dialect will use the concept of a platform object. Here I’ll explain what that means.
The Dialect Diary – The Formation of a Test Framework
I’m starting yet another new test execution framework, called Dialect. I’ll be the first to admit any “dialect” posts will be self-serving in one respect: they will be my attempt to document to myself my own thought process as I go about creating the framework. That said, I definitely wish I had a resource like this when I was first starting out. So my hope is others will find value in what I’m providing, whether or not they ever use Dialect.
Continue reading The Dialect Diary – The Formation of a Test Framework
The “Which Language Should I Learn” Dilemma
A lot of times I get asked by technical testers the following question: “What language should I learn?” The rationale for the question is obvious: there is limited time and they want to focus on that which will do them the most good. The good news is: this is a false dilemma.
Continue reading The “Which Language Should I Learn” Dilemma
The Testing Focus Shift: Back To Its Roots?
There is a large debate ongoing in the testing community about how technical a tester has to be. I actually believe that a tester has to be technical enough to implement test solutions when they are most needed or know how to gather the skills to become technical enough. Pretty vague, huh? The problem is that it really depends on what test solutions you need and the skills needed to create them.
Continue reading The Testing Focus Shift: Back To Its Roots?
Put Thought Into Naming Your Test Tools
I have a really hard time getting behind the names of many of the open source test tools that are out there. Here I want to talk about that just a little bit and what I’ve been doing to combat that. I do realize that I am probably in the vast minority of people who are concerned about this issue.
Providing Data with Lucid Sequences
This post continues directly from Using Sequences in Lucid. In this post I want to show a bit about how sequences can be parameterized, from simple variable elements in statements all the way to the use of data tables.
Using Sequences in Lucid
With the release of 0.2.0, Lucid has the ability to use sequences as part of the test description language. In this post I’ll explain what that means and we’ll go through an example that puts this concept to use.
A Spec-Based TDL Primer
There are many references out there that discuss Gherkin, which is a structuring element for your test description language (TDL). So what I’ll be offering here is really nothing new. This post is simply a relatively concise look at the TDL pieces and parts in terms of how these elements can be used in the context of Lucid or related tools.
Connect Quantity to Quality
For those of you who have read my posts on test specifications you know that I tend to focus on the idea of writing requirements as tests. This, to me, is essentially a large part of the benefit of collaboration-based approaches such as those suggested by Behavior-Driven Development (BDD) practices. (Although I still prefer Business-Driven Development, but whatever.) What I like about this approach, among other things, is that it builds in traceability. And I like that because requirements traceability was always something that I had an issue with as my career developed.