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.
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.
No comments:
Post a Comment