As many automation engineers know, we’ve been dealing with Marionette, the successor to the Firefox Selenium driver, for some time now. We’re starting to see a light at the end of the tunnel. However, I’m finding a lot of teams are still struggling with what all of this means. Here I’ll talk real briefly.
The Challenge of Testing
Awhile back I talked about what makes testing complicated. To be honest, that post is embarrassingly written as I look back on it. That said, I think there is some value in what it says. But to show how my thinking has refined, as well as become a bit more operational, let’s piggy-back on my previous “code as specification” posts and look at why testing is challenging.
Driving Design with Code as Specification
This post follows on from my code is a specification. I highly recommend reading that post to get the context because here I’m going to add a bit to the sample code from that post. This is being done to illustrate the idea of test code and production code working together to act as an executable specification. Here I’m going to focus a bit on how this has relevance to the business as well.
When Code Is The Specification
Early on I talked about business needs becoming specs that become code. More recently, in my modern testing posts, I talked about the idea of production code being the specification of behavior. I wasn’t necessarily very descriptive in all of that, however. Let’s see if I can do better here.
The Use of Tradition and Dogma in Testing
It’s become tradition — with a bit of dogma — to point to triangles and quadrants to “explain” things about testing and development. A good case in point is presented in the article Agile Testing Automation. My goal is not to critique the article but rather to use it to highlight what I see as some of the problem. So let’s subject tradition to some rational inquiry and let’s subject dogma to a bit of scrutiny.
The Integration Pact
In previous posts about the integration / integrated distinction (see part 1 and part 2 of that series), I talked about how there is in fact a distinction and provided a little rationale behind why this distinction currently matters. So now let’s talk a little “around” the concept of integration — not integrated — and see where this takes us.
Integration and Integrated, Part 2
In the previous post in this series, I talked about the counterargument of there being no distinction between integration and integrated. That post ended on a question. In this post, I will start from the presumption that there is a distinction between the terms and explore that a bit.
Integration and Integrated, Part 1
Here I’ll talk about the difference between the terms integration and integrated when applied to testing. You may read that and say “Um, there is no difference, is there?” Well, let’s talk about it.
What Can Particle Physics Teach Us About Testing?
Awhile back I talked about being cross-discipline associative. I did something similar to this approach when I asked what time travel could teach us about testing. Let’s see how this works with another domain entirely.
Continue reading What Can Particle Physics Teach Us About Testing?
Modern Testing and the Lucid Approach
Here I’ll cap off my current round of “modern testing” posts by discussing a bit about the lucid approach that I’ve brought up along the way.
Modern Testing and the Artifact Crutch
I’ve gone through a lot of posts on modern testing and I’m nearing the conclusion of my thoughts on this. (Or so we can hope, right?) Here I’ll recap a bit and then push forward.
Modern Testing and Unpacking Truths
In my previous post on modern testing and resilience, I indicated that testing and quality assurance spend a lot of their time, as disciplines, being in danger from their own practitioners. This is most often a problem when the disciplines are under pressure to change. Here I’ll focus on that a bit, with the understanding that these are obviously purely my opinions, even if they seem stated as fact.
Using Serenity with Cucumber, Part 3
Using Serenity with Cucumber, Part 2
In the first post of this series, I got us set up with a Serenity repository using Maven as our build tool. I also started us on the path of applying Cucumber-JVM by putting a feature file in place. In this post we’ll start tying Cucumber into Serenity’s runtime operations.
Using Serenity with Cucumber, Part 1
I’ve talked a bit about Serenity in previous posts as well as Cucumber-JVM. Here I’ll combine the two and talk about how to set up a simple Cucumber-style project. Along with this focus, I’ll be concentrating a bit more on the Serenity reporting as part of this.
Modern Testing and Resilient Strategy
In two previous posts (on design pressure and sources of truth) I talked about the context that a modern test team is often fitting in with. Here I’ll get more specific, particularly in regards to some strategic elements.
Screenplay Pattern with Java, Part 3
Screenplay Pattern with Java, Part 2
This post is following on the from the first post in this series. Here I’m going to dig a little further into the screenplay pattern, finishing up the execution of the test started in the first post. I’m focusing on the screenplay pattern itself here. That pattern can be applied in any programming language. I happen to be using Java, and I’m using a tool (Serenity) that already encapsulates this pattern.
Screenplay Pattern with Java, Part 1
In this tutorial post, I’ll begin covering how to apply the screenplay pattern with the Serenity framework. This is a “roll-up your sleeves and code” post. Here I will take a measured approach to demonstrating the screenplay pattern in the context of a working example.
Screenplays and Journeys, Not Page Objects
I wrote about Serenity with Java in a previous post. There I covered just the basics to get you up and running. Here I want to talk about what I think is the primary value-add of Serenity, which is its focus on the screenplay pattern. I think it’s beyond debate that automation engineers should know of this pattern and use it. It’s up for debate whether Serenity’s implementation is a good way to go about it. I leave answering that latter question to the reader. Here I just want to explore the idea as it is implemented.