Test creation order

Just digging into some old papers today, I found this old note. I think I did screenshot this long ago from a video by Sandro Mancuso. 

1. Class name: The class name is post fixed with Should. This is a pattern that was introduced by Sandro in his lectures. Since tests are probably already in the test package, we don't need to know post fix them with the word test, this class name is more BDD friendly and serves as good documentation.

2. Method name: Is concise and it explains what it does without revealing implementation detail. The words are separated with underscore so that it is easier to read than camel case in a first glance.

3. Assertion written first: By writing the assertion first we reduce the risk of introducing assumptions and over engineer. It helps keeping the code minimal and growing it progressively.

4. Action: Once  e have our assertion we will write the action. This maybe seems counter intuitive
but as you will notice, as we are writing the assertion and the action, the code is not compiling, this will force us to code the minimum required to make the test compile.

5. Setup: The last step is to add the setup. With this approach we forced our brain to focus on the behaviour and not on the state. This focus on behaviour is the key for growing the code gradually. Thinking on state first rather than behaviour can lead to assumptions and missed requirements.

This is a very interesting approach which has a lot of benefits. What do you think?

The Kick Off

What is this?
This document describes an internal(team) designed and agreed mandatory rules for the process that just precedes the development of a story, This process is commonly known as the "Kick Off".

Why?
The main reasons for this are:

• to make sure that the team is aligned/understands the story that is about to be developed
• distil the requirements given to the team by the business analyst and early spot errors in them
• revisit and adjust the scope of the story if necessary 
• create a mandatory repeatable process so the risk of early introducing an issue is less
• agree upon work that need to be done

THE KICK OFF

1. Read the story description independently
   Regardless of if we work in a pair programming environment or not, we(each member of the team individually)  will take some time in our own to read the requirements that were written in the ticket management tool(e.g JIRA). The time this first glance takes is somewhere around 5' and 20'.
2. Gather questions
   We must understand that the kick off is a team activity. We are not expected to understand everything in the requirements at 100% neither to know exactly everything that needs to be done and how it should be done. We will write down all our concerns, doubts, assumptions, questions, etc... in a list and we will keep it for the time of the kick off. Individual solutionising is not an acceptable behavoir.
3. Craft a task proposals list
   Now with our pair programmer or by our own if we don't have one, what we will do is to write down a list of proposed tasks, based on our understanding of the story so far. This list is just a draft, not a final decision. The purpose of this draft is:
   - To make visible to others our views/sense about the story in hands.
   - To make it easier for the developers to spot task parallelisation opportunities.
4. Empty acceptance test
   An empty acceptance test(just text in the Given When Then format) will serve as a conversation starter during the kick off. The propper creation of the real failing acceptance test will be done as an independent task, later since only when all is clarified in what regards to requirements, we can write an accurate and meaningful acceptance test.
5. The Kick Off
   At the kick off all the team gathers and look together at the story. The BA will start by giving a brief summary on what is the story about. Then the developers will show the empty acceptance test they've written. Now is the time to use the questions, assumptions we gather initially. If any discrepancy exist, it will be clarified by the team and the acceptance test will on spot be corrected. At this point, the story is considered to be kicked off with the team(but yet not officially marked as started).
6. Dev's talkWhen the kick off is complete and we know exactly what needs to be done, we will huddle with the rest of the colleagues to distil the proposed task list we made and agree on what tasks we can parallel. It is highly likely that after the kick off toke place that initial draft is no longer accurate at 100% so the devs will revisit it and distil the final version. This final task will be published in the same place where the requirements were published, so the progress of the story is transparent to everybody.
7. Start development
   The developers will now prepare their tools for development(e.g rebuild local DB, synchronise VCS, awake zombies...). When this is complete the developers will move the story into "dev in progress" and development begins. Good time for a coffee now ;p

Use a martial arts principle to improve your Test Driven Development skills.

In ancient Japan, martial arts were not just defence techniques, they were also  a way of life(jap. “budo”).
In this way of life they combined physical, moral and spiritual dimensions with the goal of self-improvement.

Since very young, Japanese kids would join a martial arts school, to study: karate, aikido, judo…  
They learned martial arts using a technique called “Kata”.

The “Kata” technique was based in the principle of “learn by repetition”.
By practicing exercises in a repetitive maner the learner  comes to a point where develops the ability to execute those exercises and movements in a natural and reflexive maner(“intuition”).

Today in software development the amount of trainers that recommend to use Test Driven Development Katas, is increasing.  Some would even say that the TDD katas, are the only way to learn TDD.  The original idea of the kata as a maner of learning software development was introduced by Dave Thomas(author of: The pragmatic Programmer: From Journey man to Master ).

Programming principles such as KISS(Keep It Simple and Stupid) or YAGNI(You Ain’t Gonna Need It ) are very common in the TDD philosophy, but the main mantra behind TDD is the RGR principle (Red, Green, Refactor).

From the theoretical point of view, the RGR principle seems often very simple to new TDD developers.
But when it comes to real life practice, in many occasions the complexity of the software can make less experienced developers to panic.

A great practice to avoid this is to practice a TDD kata once in a while.
Peter Norvost(author of the blog: Geek Noise), recommends to new TDD developers to do simple katas of 30 minutes every morning for 2 weeks. 

Now I will show you an example of a very simple TDD kata and then I will perform a demonstration.

KATA #1: “THE STRING CALCULATOR” (Kata description taken from: http://osherove.com/tdd-kata-1/)
1-An empty string returns zero
2-A single number returns the value
3-Two numbers, comma delimited, returns the sum
4-Two numbers, newline delimited, returns the sum
5-Three numbers, delimited either way, returns the sum
6-Negative numbers throw an exception
7-Numbers greater than 1000 are ignored

Note: Don't forget to set the quality to HD in the video player