Agile series V - TDD, UADD and BDD, briefly

Briefly put, in TDD, you write a test first, if the test fails, write only that much code to make it pass and if the test passes, write another test. The goal is to write a new unit test once the previous test has passed. Let the design evolve from this sequence.

Once the code is stable, brush it up with some re-factoring and showcase it (or present it) to  the tester for user acceptance tests. If the tester comes up with bugs or with exceptions, go back to the previous step of writing more unit tests to be able to determine what code should be written for the user acceptance to happen!

In UADD, start backwards. Get the UAC and then start your TDD ! Simple !

BDD is just a step further ! :)

http://ravichandranjv.blogspot.in/2012/11/bdd-with-nbehave-starter-example.html
http://ravichandranjv.blogspot.in/2012/11/behavior-driven-development-with-tumbler.html

Happy TDD & UADD !

Agile series IV - after refactor!

The method "Subtract" (It was "Substract" initially. In this snapshot, you see a red double dash under the "t" because I had corrected the spelling but not rebuilt it!) was not called because of misspelling and the resulting coverage is below!

Added try-catch and refactored all the return statements into individual statements

After full refactor..

Agile series III - UAT with Slim/Fitnesse

Failing tests because user input is also negative! Wrong expectations ?

3 Failing tests and 2 exceptions! Wrong expectations or wrong code?

Agile series II - The not-so-perfect world!

The previous post is all about how perfect the software world is, given perfect behaviour of code! But, nothing in our knowledgeable world is perfect because that is the reason everything, in our known world, constantly evolves or "changes".

And so, we will start with the "assumption" that our code is perfect and start giving it all kinds of "whacky" inputs! Whacky means that we do everything that goes against the expectations of the "perfect" code but with the goal of achieving 100 % code coverage ! For instance, we will provide a combination of negative and positive and zero values to the domain class and see how it behaves! Simple !

And this is what the user, who did not create the code and therefore, does not know. So, here ends unit testing and  begins User Acceptance Testing where we supply the code with all kinds of inputs and the entity that will do it should be some entity that did not write the code - it could be the end user, the customer, the tester or just about anybody.

If there is a user interface, we could use the input mode to take the input; if not, we supply it through an automated testing tool like Fitnesse!

And from here starts testing for exceptions, wrong inputs and unformatted inputs.

The passing UAT test with FitNesse/Slim framework is below

This is the fitnesse way of doing it! Write a separate fixture class and test it with two public fields, firstValue and secondValue, and have different methods for testing. That is, just to do UAT you need a separate Fixture class written by the dev.

The Slim way is straightforward. Just consume the same domain class for UAT!

Below is the Slim script for the same class that had been unit tested and for which the code coverage was 100 %.

Contd...in subsequent posts.