Skip to main content

Behavior Driven Test Cases

I have read a bit on BDD. But none of the theory seemed appealing enough that I would be like “hai ! this is cool. Let’s do this”.
Probably because I am a lazy tester or more appropriately test case writer (unit test that is J).

What supposed to happen ?
TDD. Write test cases first àdrive the development from there ( based on whatever model is chosen or appropriate).

What actually happens ?
As much as the next guy wants to throw theory and technical jargons I’m not really sure how many mid-scale project processes actually follow TDD throughout the entire development phase, let alone maintenance phase(where it’s most important) OR BDD for that matter.

What I do mostly?
The truth is (at least if I speak for myself) I have not followed through a proper TDD process. Yes there always exist some test cases that are written and thrown into build process so that we can use it in future.
Even more sometimes we write the test cases after the feature is developed.
But I don’t think that’s TDD.

My reasons for why I am reluctant ( sort of ):
  • Writing test cases is difficult (in terms of extra work).
Usually the attitude is like “I have written the feature and I have executed the code over and over until I got it working. So it’s tested”. Which is fine.

But what about when we change / develop some related feature and want to make sure whether our previously developed feature is still working fine ?

Or the other guy did not break things collectively ?

Yeah! Manually testing it over and over is lame ( even though I do it pretty much on a daily/regular basis ).!

  • Maintaining test cases is even more difficult.
For example: we started making a horse as our feature. And is done and tested. Then client said they want an unicorn. But along the way of putting the “horn” and “wings” on the “horse” resulted in changing the some basic anatomy about the “horse” like “it can freaking fly now”. So our old test cases will fail (well at least mostly). And I wouldn’t want to write or modify them is again (or at least will feel like my hands are heavy).

The cool things:
The theory of “BDD” and “BDD vs TDD” confused me big time. And of course them cowboys put their opinions the way they found it good (which obviously is conflicting).
But the cool thing I have found is a tool called cucumber (https://cucumber.io/). Cucumber is awesome.
AND using cucumber to write test cases will fit in just fine with my laziness to write test cases. I have made peace with myself that I am not going to do BDD or TDD but I will write test cases.

The benefits:
From now on I will focus on test cases written using cucumber (thus somewhat bdd).
Lets take the example of “the client is turning the horse into an unicorn”.
So the behaviour of the horse was:
  • It could run
  • It would eat
Making it an unicorn will not change its behaviour rather will add another:
  • It will fly
So we will only have to write 1 more test method to test flight. And as it is “test case written in cucumber which focuses on behaviour” we won’t have to refactor our test methods because we refactored our code.

The other cool things are:
  • I can literally copy-paste user stories to write my test cases ( because cucumber is awesome)
  • It’s English language. That means I can read through the test cases and understand what one is trying to test (even though my only skill is writng emails)
  • Test method are variable driven (thanks to cucumber).
Thus I can avoid writing bunch of Mocks which can and usually does become absolutely useless at later point.
Hence, I am avoiding “hard coding” things.
  • The “test results” are descriptive so it can be used ( as DFO ) as output of tests for clients.
 Ofcourse the solution needs to be designed properly. Otherwise it’s a lost cause anyway.

 Example:

This is how my “service” test cases looks like:

  • So when I refactored my service layer to use “comman pattern” I did not have to rewrite any of my test cases at all.
  • This is also replacing Mock object.
  • As my “Test” project contains its own config and because I am using “code first” I can create/update or change datasourse ( here in actual application I am using SQL Server but for test I am using “local storage”).
 This is the “test results” look like:


In summary I can be lazy and still write test cases so that I can keep using them in maintenance phase possibly without writing anything on test method.

This is the pattern I followed ( but it’s a little bit weird as Read part is also in same the repo as the write .. but this example project was simple enough)

Comments

Popular posts from this blog

Reimagining Logs: Building AI powered Conversational Observability System

It is mid-2025 and the cogs of AI are at full speed. So we (I and Mobin) decided to do our own AI project. We called it "IntelliLogs".  IntelliLogs at a glance: Demo:  https://www.youtube.com/watch?v=OXMlORwyMQk In this post I will describe why we did what we did, what is it that we did and how we did it. I will share my personal experience. I am hoping this will, at least, be an interesting read. Table of contents: Why IntelliLogs What is IntelliLogs How IntelliLogs was developed Future of IntelliLogs Conclusion References Why IntelliLogs: Personal motivation ðŸ’ª to this were: Explore and experience what does an AI app look like from an architectural and engineering perspective Explore the realm of Huge LLMs (eg: GPT-4.1-170B,  Gemini Pro etc) vs small LLMs (eg: granite-7b, gemma-4b) Explore the possibilities of model tuning / making a model without being a data scientist. How easy or hard it is, what tools available etc. We also wanted to tackle a "not too far from ...

Openshift-Powered Homelab | Why, What, How

I wanted to build a Homelab for some time but it was taking a backseat as I always had access to cloud environments (eg: cloud accounts, VMware DC etc) and the use cases I was focusing on didn't really warrant for one. But lately, some new developments and opportunities in the industry triggered the need to explore use cases in a bare-metal server environment, ultimately leading to the built of my own homelab, called MetalSNO. In this post, I will discuss some of my key reasons for building a homelab, the goals I set for it, and the process I followed to building one from scratch. I'll conclude with some reflections on whether it was truly worth it and what I plan to do with it going forward. Compelling reasons (The Why ) My uses cases for a homelab weren't about hosting plex server, home automation etc (I have them on Raspberry PIs for some years now). My Homelab is really about exploring technologies and concepts that are on par with industry trend. Below are some of the ...

Understanding The Ingress and The Mesh components of Service Mesh

I wrote about the key concepts about service mesh and how to evaluate the requirements for a service mesh in my previous post here:  Deciphering the hype of Service Mesh . This post is a follow up from there covering the technical aspects. Part 1:   Deciphering the hype of Service Mesh Part 2:   Understanding The Ingress and The Mesh components of Service Mesh. Part 3: Uderstanding the observability component of Service Mesh (TBD in another post).  Almost all popular service mesh technologies/tools (eg: Istio, LinkerD) have both ingress and mesh capabilities. Conceptually, I see them as 2 mutually exclusive domain (integrated nicely by the underlying tool). Understanding  the ingress  and  the mesh  components individually, such as what they offer, what I can do with them etc, was the basic building block to my understanding of service mesh technology as a whole. This is arguably the most mis-represented topic in the internet. So, I thought,...

CKA Exam; May 2024: My take on it and cheat sheet

So, I finally got the little green tick of having CKA certification in my certification list. I put off this exam for so long that it seriously became not funny anymore. The internet has quite literally way more than 1000 posts on this topic. But what harm would one more post cause? So here's mine. I will write it from my perspective. I am writing this post just in case if anyone benefits from it, as I predict there could be many on the same boat as me. Background: Kubernetes, modern application architecture, DevSecOps etc are not new territory for me. In fact, I think I am fairly versed in K8s and related tech stack. But due my own imposter syndrome I have been putting off sitting the CKA exam. However, last week I thought about the CKA as "just another approval for my skills" and got the nudge to sit the exam.  Here's what I did till the day I sat for the exam. (Everybody is different but the below worked for me the best) The preparation: As I have been working with...

Exception Handling With Exception Policy

This is how I would think of an application at the very basic level: Now this works great. But one thing that is missing in this picture is Exception Handling . In many cases we pay very less attention to it and take it as "we'll cross that bridge when it'll come to that". We can get away with this as in many application as exceptions does not stop it from being in the state "is the application working" as long as we code it carefully and at the very least handling the exceptions in code blocks. This works. But we end up having try catch and if else everywhere and often with messy or no direction to what type of exception is to be handled where and how. Nonetheless, when it comes down an enhancement that depends upon different types exceptions, we will end up writing/modifying code every where, resulting in even messier code. I'm sure no one wants that. Even, in scenarios, a custom handler is not the answer either. Cause this w...