There are a few things I’ve not tried yet. Sadly, possibly, I’ve not tried karaoke, and I’ve not tried kite boarding. I am however getting my first experience in applying Given-When-Then in describing product behaviors on a real project. I’m very excited at the possibility of merging business behavior with automation.
I engaged Specification By Example, I attended hands-on training, and I have participated in periodic drive-by creations of GWT scenarios. I felt very ready. Hurtling into some of our project’s first story cards, I was shocked to review GWT that contained behavior AND, take a deep breath, implementation details.
As an example, I offer a scenario from an API I wrote for a website.
GIVEN active flights exist,
WHEN the website requests a list of active flights,
THEN the reply includes all active flights
AND their unique identifier,
AND their altitude,
AND their last update.
This GWT represents my interpretation of what I have learned and, as noted above, my limited experience. Here is how the same scenario might appear if I violate one of the most fundamental rules.
GIVEN the active_flight field indicates true,
WHEN the website executes GET against the activelist API,
THEN the response contains an HTML table detailing the flight’s GUID,
AND the flight’s altitude as an integer,
AND the last update in a UTC format.
In my opinion, this is more than a violation of the “no implementation details” rule. This description locks the behavior to a specific column of a database, defines the verb and API name, prescribes a specific rendering method, and calls out individual field data types. Its as if a developer provided the information they needed to implement the scenario to an analyst.
While this is clearly an extreme example, I recently read such a scenario. When I asked, the reason implementation details were included was because this is a “technical story card” (different from a “business story card”), and because it is easier to provide all the information in one place.
(ahem) Bull. Shit.
In my opinion, this method of practicing and segregating GWT ignores one of its most quintessential and valuable aspects: collaboration. Yes, I read Specification By Example and attended training. I learned the mechanics but in both cases I left with something more.
I perceived an overwhelming feeling that during a conversation about product details between an analyst, a tester, and a developer, these few people begin to share not only their ideas but their understanding. It IS NOT the GWT itself that encourages automation or reduces defects rather it is those precious minutes where an honest, introspective, and respectful dialog clarifies the behavior of a simple product.
Just writing GWT provides a small window into a product. Collaborating over the value of a specific business behavior encourages teamwork and quality where everyone can take pride and feel their contribution matters.