So what exactly is the difference between KDT and BDT?

If we go googling, we will eventually see that:

  • Data Driven Testing (DDT) - test data is "independent" from code;
  • Keyword Driven Testing (KDT) - test steps and test data are "independent" from code;
  • Behaviour Driven Testing (BDT) - cool business oriented syntax! Engage your shareholders!! Best approach since sliced bread!!!
When you actually write the definitions back to back you can clearly see that any KDT framework is also DDT, and any BDT is also KDT and DDT.

So what separates BDT from KDT? The cool syntax (given-when-then), which is usually the first thing mentioned, doesn't actually do much. If you transform your keyword from <user clicks button> to <when jimmy clicks the button>, you will not actually add any value.

BDT has two closely related features that both give the same benefit - test cases are more readable and more maintainable. You could say it's the OOP of test automation if you were feeling generous.
The first one is the focus on user, um, hoot-giving rather than user actions. The user doesn't give a hoot what buttons he has to press to create an issue, he just wants it done. When you come back to a test case you wrote months ago, "why should I give a hoot about any of this?" will be a pretty relevant question.
The second one is the size of the test cases. You feel like an idiot writing "when user clicks button X AND user clicks button Y AND user fills form AND ..." and that's by design. By focusing on hoot-giving, grouping actions together and making your test cases more focused you can keep your test cases within a certain size limit. When you need to review 100 test cases someone else wrote, 6 lines is easier to read than 15.

And when you read these cool advantages again and again, you will realise that BDT is just KDT with strict test case design rules. Your framework will usually only be different at the highest level of abstraction.
Although I have to note that not following BDT rules can lead one to dark and insane places best left undiscovered, such as 1000-line Excel files with keywords.

Коментарі

Дописати коментар

Популярні дописи з цього блогу

What the heck is polymorphism?

Google it, and you are bound to find places where function overloading is cited as an example of polymorphism. But does being able to not name your methods differently for different argument sets really qualify as one of the 3 fundamental OOP principles? Is going from void FeedCookie(Cookie inputCookie); void FeedMeat(Meat inputMeat); to void Feed(Cookie inputCookie); void Feed(Meat inputMeat); really something that you can't do OOP without? It isn't, in fact there are cases where trying to save a bit of time with this can backfire. Just go for the proper answer: interfaces are polymorphism, because signatures are the same but the underlying methods can be completely different. And you really can't do OOP without them.
Докладніше

Do you prefer working in a team or alone?

I prefer working alone, without all those distracting "colleagues". Why can't I work from my cabin in the woods? Why are they forcing me to work in a team of peons who question my wisdom??? Plenty of people prefer to work alone. However, working in a team is simply more efficient, even if your tasks are not closely related. This is called the synergy effect - a team doing better than the same number of people separately. Two reasons for this should be obvious even to someone who knows jack about psychology such as myself: Truth is born in arguments - it is impossible to be right every time and teammates will usually see things you have missed, even if you supposedly know more than they do; Knowledge use and sharing - people know different things, sharing knowledge and helping others when your knowledge is required for their tasks makes everyone do better. So if someone asks you this, the correct answer would probably be: I prefer to work in teams because team...
Докладніше