#behavior driven design

#unittesting and #tdd for #developers with @6figuredev hosts @matsubonsai and @claytonhunt_104

Most of us have tried to get better about unit testing, with varying degrees of success. Some folks even manage to succeed. Whether it is due to inexperience, frameworks designed without consideration of testing, or simple management resistance to regular testing, the challenges to getting it right are substantial. However, the rewards are great, which is why we’ve brought John Callaway and…

BDD Done easy – The three levels of BDD — The IT Risk Manager

The easy way to do BDD is “Working Backwards“(1). Sadly “Working Backwards” is a principle that few people are aware of and even fewer practice. The other poorly understood aspect of BDD is that there are three different levels of scenarios(2). The three levels are: The user based view where we ignore which systems perform […]

Scenario: Everyone is asking about development methodologies Given:I…

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:

Source code : https://bitbucket.org/ali_nahid/kitchensinkbdd/overview

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)