It is rare that different frameworks can be wired together without facing some glitch in the implementation path. Sometimes, the technologies pose problems, some other times, the tools are not available.
For instance, on a previous occasion, I tried the three with the combination of Slim, C#, NUnit and it developed hiccups because, being a web application, the Javascript/jQuery code could not be as fluently unit tested even though I tried Jasmine and Slim posed yet another problem in that it required separate DLLs to be created for the functional tests to happen, which was far too cumbersome because it meant that components were getting created just so that some tests [to make a framework work] could be performed.
Not what a good design is - you do not create components to make tests succeed, you create components to make the system function properly!
The key to creating a great design, the Agile way, is to let the tests drive the design, not just the development. This can be possible only by getting the requirements right, right upfront. To achieve this, BDD (Behavior Driven Development) framework comes handy.
In this context, naming this framework as a Testing Behavior [Business Driven Behavior] for better User Acceptance (TBUA) would be the closest acronym to describe it.
BDD
There are many tools and definitions that go around for BDD.
The most famous ones are
1. promise,
2. given, when, then...,
3. should and expect
style of unit testing and,
what I consider to be true behavior driven development -
4. scenario testing based unit tests.
The flavors are different with the intent same - that of providing for as many tests as possible for any given requirement [line of code].
For instance, a Business requirement is to open a XML file, read the contents and get a string as result.
The test scenarios for this business requirement are as follows:
1. Check if file exists
2. Check if file is an XML [filename contains .xml extension]
3. Check if valid XML
4. Check if string generated from XML
The difference between the BDD [without scenario testing] and the BDD [with scenario testing] is highlighted in the above screenshot.
The scenario as described by the Business Rule is to check if the file exists.
But since there is only the business requirement available at this stage, and no coding done yet, the method "openFile" does not exist. What this means is that BDD helps track the business requirements correctly. With scenario tests, it becomes easier to keep the development strictly within the business context.
The scenario has been documented in fitnesse's slimjs tool. Expand the scenario name
This part of the BDD is so essential because it helps trace the entire lifecycle of development from the time the Business Analyst comes up with the business rules based on the requirements and elaborates the scenarios for user acceptance to the time when UACs are contested over.
The rest of the scenarios are
The scenario, check if file extension is xml, does not call a method because it is well possible that it would be handled by the openFile method.
This choice is what makes the Agile way of development so different because deferring the decision till later when coding actually will reveal the possibilities through design evolved from unit tests, allows for a higher code quality.
At this point of the lifecycle, the BDD has just started. Some scenarios have been obtained from user stories and scenario tests have been written for it.
The main reason for writing scenario tests is so as to be able to wire up the scenarios with functional tests, after the unit tests [part of TDD] have completed.
Please note it is not necessary to do scenario testing to do BDD; it just enhances the Agile experience more.
Next part: Deriving unit tests from scenario tests
For instance, on a previous occasion, I tried the three with the combination of Slim, C#, NUnit and it developed hiccups because, being a web application, the Javascript/jQuery code could not be as fluently unit tested even though I tried Jasmine and Slim posed yet another problem in that it required separate DLLs to be created for the functional tests to happen, which was far too cumbersome because it meant that components were getting created just so that some tests [to make a framework work] could be performed.
Not what a good design is - you do not create components to make tests succeed, you create components to make the system function properly!
The key to creating a great design, the Agile way, is to let the tests drive the design, not just the development. This can be possible only by getting the requirements right, right upfront. To achieve this, BDD (Behavior Driven Development) framework comes handy.
In this context, naming this framework as a Testing Behavior [Business Driven Behavior] for better User Acceptance (TBUA) would be the closest acronym to describe it.
BDD
There are many tools and definitions that go around for BDD.
The most famous ones are
1. promise,
2. given, when, then...,
3. should and expect
style of unit testing and,
what I consider to be true behavior driven development -
4. scenario testing based unit tests.
The flavors are different with the intent same - that of providing for as many tests as possible for any given requirement [line of code].
For instance, a Business requirement is to open a XML file, read the contents and get a string as result.
The test scenarios for this business requirement are as follows:
1. Check if file exists
2. Check if file is an XML [filename contains .xml extension]
3. Check if valid XML
4. Check if string generated from XML
The difference between the BDD [without scenario testing] and the BDD [with scenario testing] is highlighted in the above screenshot.
The scenario as described by the Business Rule is to check if the file exists.
But since there is only the business requirement available at this stage, and no coding done yet, the method "openFile" does not exist. What this means is that BDD helps track the business requirements correctly. With scenario tests, it becomes easier to keep the development strictly within the business context.
The scenario has been documented in fitnesse's slimjs tool. Expand the scenario name
This part of the BDD is so essential because it helps trace the entire lifecycle of development from the time the Business Analyst comes up with the business rules based on the requirements and elaborates the scenarios for user acceptance to the time when UACs are contested over.
The rest of the scenarios are
The scenario, check if file extension is xml, does not call a method because it is well possible that it would be handled by the openFile method.
This choice is what makes the Agile way of development so different because deferring the decision till later when coding actually will reveal the possibilities through design evolved from unit tests, allows for a higher code quality.
At this point of the lifecycle, the BDD has just started. Some scenarios have been obtained from user stories and scenario tests have been written for it.
The main reason for writing scenario tests is so as to be able to wire up the scenarios with functional tests, after the unit tests [part of TDD] have completed.
Please note it is not necessary to do scenario testing to do BDD; it just enhances the Agile experience more.
Next part: Deriving unit tests from scenario tests
