Background
I started to think more about Given, When, Then when I got into software testing. In this post, I told you that used to spend a lot of time improving my coding skills by watching videos in Laracasts. There are a couple of testing video series in there and in almost all of them, they write the tests in the same way:
If you think about this, you can cover so much ground with such a simple way of thinking. And if you structure your tests in the same way, you end up with code that is very simple and easy to understand, making them very straight to the point.
I started to think and use more and more this concept. Not only for testing but pretty much for all steps of a feature’s lifecycle.
Let’s jump into a technical example.
Technical Example
Let’s imagine that you and I have a Pet Store website and, during this month, we have a 10% discount on our Premium subscription. So, every time a free account user login we want to show them a message saying:
Hey 👋 Subscribe to Premium now with a 10% discount!
At this point and technically speaking, we want to create an endpoint from where we can get a subscription discount for a given user: GET /v1/discounts
Planning
You’re the one creating this endpoint! We start by getting together and creating a working ticket. In there, we want to ensure that we include something called Acceptance Criteria. When you finish your work, you’ll pass the ticket to me. I’ll be responsible to test it and ensuring that what you implemented covers every use case that we wrote on that Acceptance Criteria. Let’s check the ticket!
Development & Testing
You picked up the ticket from the queue and put your hands to work! You ended up developing a pretty simple logic.
In the DiscountsController, you added a getSubscriptionDiscountForUser method. That method receives the User object resolved from a token passed in the request (@UserToken() decorator will do that for you). You return undefined when the user.subscription is already premium or a new instance of Discount with the value.
To ensure that this works as expected, you created two tests for the new code:
- The first one verifies that you get the 10% discount when a user subscription is free.
- The second one verifies that you get no discount when a user subscription is a premium.
Let’s see those tests!
Nice one! I noticed that you used a similar approach to the one in the Acceptance Criteria of the ticket to create your tests.
QA
You finished your work and passed me the ticket for some QA. Let’s bring that ticket back!
Ok! So we need 2 users: one in a free account and a second in a premium account. After getting those, I’ll use an HTTP client tool and execute two requests:
Perfect! Now I got the 10% discount for the user in a free account and got nothing for the user in the premium account.
As you probably noticed, we used this Given, When, Then concept in different steps: planning, development, testing and QA. This is something that is not oriented to testing but a way of thinking that can help you through many steps.
Let’s take a look at this concept applied to non-technical matters.
Applied to Personal Life
As I started to use this Given, When, Then daily at work, I noticed that I was also applying this in my personal life.
If you pay a little attention to your thoughts over your day, you’ll notice that, without even planning on it, probably your brain is already behaving in that way.
I’ll give you one of my examples! A couple of months ago, my partner and I were thinking about adopting a second cat. At first, I was very reluctant about it as I was afraid of Pookie (first cat) not receiving the kitten well. As for any important decision, I started to think more about it: upsides and downsides. As I was listing all of these points in my head I started to structure them in a Given, When, Then way, like this:
Conclusion
Given, When, Then are just three simple words that combined create this simple and logical way of thinking. It is something that your brain does every day without you even noticing. You just need to be more aware. As it naturally occurs, If you take advantage of that flow of thinking you can easily apply it to pretty much anything.
As a software engineer, this has been helping me through most of the development cycle steps of a feature. It is also useful to improve team members’ communication by creating this kind of standard way of defining what is expected to happen. This way, developers can take advantage of that information to guide them through the coding process. Testers take that statement as their source of truth for what’s expected when testing a feature.
I hope you’ve enjoyed it, cheers! 👋
P.S. The cats are now each other besties! 🐈🐈
