BDD (Behavior Development Driven) and TDD are topics that are not new (my first post was in 2011).
Now that we have VSO, Visual Studio Online and Microsoft Azure, we can be even more Agile !
Without debating weather or not one should use BDD or TDD, this post focuses on how to do it the BDD way, and show that SpecFlow could handle easily French.
OBJECTIVE: From a “regular” specification (waterfall way) we are going to:
- Convert it into BDD,
- Write it down into Microsoft TFS / VSO, via Excel
- Implementer the Unit tests (helped by the BDD auto-generated code),
- The Dev is naturally going to ask questions to the PO (Product Owner) and one of the aim of BDD is to force them to talk ! and have a common language without having any misleading specification.
- Implements the code
- Performing Refactoring
- Prove the PO that the « Definition Of Done » based on the « Given-When-Then » of the BDD is compliant
- Il our case, I chose to implement with a 100%Code Coverage, since this is a sensitive and critical functionality
- With 100% of Code Coverage, even a slightest modification of the specs will be detected by the test harnesses and the Build machine.
Here is the “regular” Specification
| Screen | Role | Profile | |||
| Visiteur | Manager | Utilisateur central | Admin | ||
| Ecran d 'accueil | Navigation | x | x | x | x |
| Activité prévisionnelle | Lecture | x | x | x | x |
| Saisie | x | x | x | ||
| Export csv | x | x | x | x | |
| Performance | Lecture | x | x | x | x |
| Import & Export | Lecture |
| x | x | |
| Lancement import | x | x | |||
| Lancement export | x | ||||
| Utilisateurs | Lecture | x | x | x | |
| Création / Modification |
| x | |||
| Paramètres | Lecture | x | x | ||
| Saisie alertes | x | x | |||
| Saisie paramètres généraux | x | ||||
| Saisie paramètres généraux | x |
STEP 1: Convert this table into BDD (In Order To – As a – I want ; and Given-When-Then)
as well as other Product Backlog Items directly into EXCEL (with a 2-way connection to Microsoft TFS / VSO)
If you are irritated with EXCEL, just use MS Project, Word or the TFS Web portal (below).
STEP 2: Let focus on one specific PBI
(displayed with IntelliSense within Visual Studio with the SpecFlow Add-on. Hence, one cannot write any specification since it is going to be compiled by MS Build or Visual Studio)
ETAPE 3: Let SpecFlow autogenerate the test harnesses from the BDD specification
According the the methodology « Red, Green, Refactor » (the you MUST ALWAYS follow in this order else you’ll end-up having tests that returns always True or you’ll forget to « refactor », …),
- I write the tests within the BDD auto-generated test hanesses. I run the tests that should fail (Red) {which is normal since I don’t have any code yet !}.
- I start implementing my 1rst code so that the tests becomes Green (with refactoring yet, so that if it’s wrong… you should fail fast)
- Once green, it’s time to Refactor which is great, since my code is so ugly that TFS refuses to archive my code.
BENEFIT N°1 : Refactoring
The refactoring forces me to have few iterations :
- with ugly code: Maintainability Index = 20 and cyclomatic complexity = 105 (i.e. so complex that no one will want to maintain my code!! where one would say “Yes, but you know, this is a very complex use case, and I had to code 106 line of code! Which is obviously a bad excuse to produce bad code)
- with less ugly code (Maintenability Index = 59 ; cyclomatic complexity = 63)
- with maintainable code that fits into half-a-screen (Maintenability Index = 72 i.e. very maintainable; cyclomatic complexity = 28 i.e. not complex).
Rappel: « Red, Green, Refactor » reminds me that my code can still be refactored to be even better… but at some point we have to deliver the code !
BENEFIT N°2 :
The code is centralized, which seams to be so obvious BUT the fact is that I can still find numerous projects with logic hardcoded into the GUI.
BENEFIT N°3 :
The code is protected by 100% of Code Coverage . i.e the slightest modification of the spec will be detected by VSO / TFS.
To cover the 100% of the needs, a hundred of tests are needed (since initially a hundred of line of code). They are wrapped up into only 2 BDD tests that represents 95+5 = 100 ms to execute automatically everytime a check-in is performed.
In the contrary, a “manual test” would have been boring to perform during hours.
The 100% of code coverage highlighted in blue ; even Throw Exceptions are tested to reach the 100%
BENEFIT N°4 : Everything is integrated to Visual Studio and Microsoft Team Foundation Server (TFS) or Visual Studio Online (VSO), with Continuous Deployment on Microsoft Azure
BENEFIT N°5: Have you ever read the specification ??
Now with BDD, the Spec becomes part of the « Definition Of Done » (DoD) and most importantly the specification are “bare bone” (i.e. you don’t write unnecessary text) and things that contradicts themselves are sometimes detected by the compiler.
That’s the end of the era where Product Owner would spend days and months to write specifications that are never read, or best are out of date and never synched with the code. Here the Word document is automatically generated by the Given-When-Then acceptance criteria.
