TDD Survey 2017

I created a survey on TDD .

The aim was to uncover any patterns in usage, and discover issues that people face.

The survey was sent out via my personal twitter and facebook feeds. It was also sent the link out via codebar slack notifications and to brighton alt.net. The spread of developer experience was fairly mixed. However, it would have been good to add a section to the questionnaire to explore that.

Summary

The most popular opinions were:

• I use TDD often at work. 42%
• I find it useful, I wish we used it more. 61%
• Best when developing a brand new project with no dependencies 8.2 / 10
• When I code I write a test and then some code to make it pass, refactoring when it passes. 40%
• It’s a bit slower for me to do TDD, but it saves time in the long term. 61%

 

Full results

The results from 36 responses:

 

1.When have you used TDD?

Other:

• For all production code and other more full-fledged code.

2.How do you rate TDD in general?

3.How do you rate using TDD in the following scenarios?

 

4.When you code, how do you generally check it works?

Other:

• it varies a great deal, depending on the problem I am trying to solve.

• It depends on context and language. In Haskell, it’s not much required, but a few tests after the fact are appropriate. Usually, if it compiles, it works. In F#, sometimes test-first works best, but sometimes, again, test-after is better, because the trick is to get the code to compile. In C#, TDD is a must for me. I don’t trust C# without tests.

5.How much longer does it take you to use TDD?

6.Describe your own experience of TDD in a few sentences

• Makes solutions simpler and easier to maintain.

• I like out side in aproach as it keeps you on things that are important. TDD is a different mindset. People only realise that when they are used to this approach.

• I find TDD most useful for refactoring.

• Sometimes it’s hard to do it in a legacy codebase

• Safety, I know when I broke stuff. I can’t think of details upfront, I discover them as I test drive the code.

• Ultimately TDD is one tool of many in developing – it’s gone a bit out of fashion with having much faster deployment cycled (with continuous deployment). Hugely useful in terms of documentation and confidence when refactoring, but the biggest curve is having to know what you want to build up front.

• In my opinion, TDD helps you: – Make incremental progress by slicing things to smaller chunks – Write enough code than coding and keep on coding – Confidently refactor – Communicate the intent of the code, if tests are written well – Lastly, to capture regression issues and deliver confidently

• cyber-dojo.org is the place to go for groups wanting to practice TDD

• I tend to refactor several times to get the types I want, and then add tests at the external interface of the API for cases where the types can’t “make illegal states unrepresentable”. TDD can in contrast be very useful when working with very dynamic data which is not easily described in the exact logic of a type system, such as refactoring legacy code (where the original intent has been lost!) or dealing with “messy” data such as parsing user input.

• The more logic, the more helpful I find TDD.

• I’ve found TDD (test-first, one test at a time, writing just enough implementation code to make the test pass, then refactor, then move on to the next test) particularly helpful when working alone, or as a documentation device (reading through a well-written test helps understand the intended functionality of the code). I’ve had some trouble being disciplined enough to apply the “refactor” part of the red-green-refactor cycle, as I’m usually impatient to move on to the next test. This way, refactoring work tends to pile up and become less manageable. Also, while I know that the cycle mentioned above should also include a fourth phase (refactor the *test code*), I rarely if ever do it, so the test code usually remains just how it was written. I also see a problem with tests that were useful during the TDD process itself (to help guide the implementation) but don’t add any value once the implementation is completed. Those tests should be removed, but here, again, I lack the discipline to do so. This can lead to a bloated, slower test suite. Finally, especially with a new language or framework or even a new dependency it can take quite some time before the TDD process feels fluid, i.e. before the test harness is set up properly, such that testing can occur after every tiny change, at the push of a button.

• It makes you really think about your code.

• useful but time consuming

• It’s surprising just how fast I get lost and have seemingly unsolvable bugs when I write code without tests!

• Its enormously useful for focusing my thoughts on defining the problem I’m trying to solve, on solving the problem and breaking up the problem into small chunks. It’s also very useful when adding new features, changing the code in some way and debugging.

• I think it’s most useful when you have a specific goal in mind, and you have a good idea what your approach is going to be. If you’re implementing a new feature and have no idea at all how you’re going to do it, I think you’ll spend just as much time (if not more time) editing the initial tests you wrote than the time it took to implement the feature’s code

• Useful in OOP. Not quite so much in statically-typed functional languages.

• Good when you know the domain problem enough Can get in the way if not, I like to prototype first in this case

• I really enjoy it when I do it, but find setting up suitable test data is often a blocker, and needs careful consideration. Often come across tests written by others that are brittle – meaning I end up taking longer to make changes as I have to fix those tests too.

• Great

• Reading about it makes me jealous and I want to use it in my job.

• Very useful for bug fixes. Difficult to encourage others to use + needs to be part of team culture to work

Feedback

Thanks to all that contributed. Please find the survey here if you wish to add to it. Also, feel free to add comments below, perhaps on your interpretation of the results?

Advertisement

Answers – Annual Geek Christmas Quiz – 2015

Here are the answers to the post from last week – Xmas Geek Quiz!

Films/Sci-Fi

1. Luke Skywalker’s name was originally written as Luke Starkiller
2. J.J. Abrams directed the latest Star Wars film
3. Siths nearly always have red light sabers. 
4. 2001 A space odyssey was released in 1968
5. Blade runner was based the book ‘Do Androids Dream of Electric Sheep’
6. Harry Potter’s Wand is 11 inches

Taglines – what was the film?

1. In space no-one can hear you scream – Alien
2. To boldly go where no man has gone before – Star Trek?
3. An adventure 65 million years in the making. – Jurassic Park
4. It’s Christmas Eve In L.A. And The Party Action’s About To Explode… On The Fortieth Floor! – Die Hard
5. We’re all in it together – Brazil
6. Nothing On Earth Could Come Between Them – Titanic

Computers

1. EEPROM stands for Electronically Erasable Programmable Read Only Memory
2. 12 principles in the Agile Manifesto
3. FORTRAN stands for Formula Translating System
4. COBOL stands for Common Object Business Oriented Language
5. Oct 31 = Dec 25 (31 in base 8 corresponds with 25 base 10). The punchline to the geek joke ‘why do programmers get mixed up between Halloween and Xmas’
6. Moore’s Law – the number of transistors (or the processing speed) in a computer circuit doubles every 2 years

Science

1. The largest moon in the solar system is Ganymede
2. The ISS travels at 5 miles per second, or 17,150 MPH
3. Corn Flakes were invented as part of J. Kellog’s health regimen to prevent masturbation!
4. up, down, strange, charm, top, and bottom are quarks
5. The first law of thermodynamics states that heat energy cannot be created or destroyed. Also known as the principle of conservation of energy
6. Tetris blocks are tetrominoes

People

1. Ada Lovelace programmed Charles Babbage’s difference engine
2. Tony Hoare’s ‘Billion Dollar Mistake’ was the Null Reference
3. Kellogg and Rice invented the dynamic loudspeaker
4. Cilla Black was 2015’s most googled term in the UK 
5. The first Briton in Space was Helen Sharman in 1991
6. Isaac Newton invented the cat flap?

Picture Round

What are the missing country codes?

1 JE

2 SE

3 AT

4 RO

5 BG

6 GI

Famous RegEx

what is it matching?

7) [ -~]

• All printable ASCII characters

8) ^(.)(.)\2\1$

• 4 letter palindromes – e.g. ABBA, NOON, BOOB

9) /^#?([a-f0-9]{6}|[a-f0-9]{3})$/

• Hexadecimals e.g. #0031da- also HTML colour codes

10) /^<([a-z]+)([^<]+)*(?:>(.*)<\/\1>|\s+\/>)$/

• HTML Tags

11) ^(([0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|25[0-5])\.){3}([0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|25[0-5])$

• IP Addresses

12) \A(?:[a-z0-9!#$%&’*+/=?^_`{|}~-]+(?:\.[a-z0-9!#$%&’*+/=?^_`{|}~-]+)*

 |  “(?:[\x01-\x08\x0b\x0c\x0e-\x1f\x21\x23-\x5b\x5d-\x7f]

     |  \\[\x01-\x09\x0b\x0c\x0e-\x7f])*”)

@ (?:(?:[a-z0-9](?:[a-z0-9-]*[a-z0-9])?\.)+[a-z0-9](?:[a-z0-9-]*[a-z0-9])?

 |  \[(?:(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.){3}

      (?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?|[a-z0-9-]*[a-z0-9]:

         (?:[\x01-\x08\x0b\x0c\x0e-\x1f\x21-\x5a\x53-\x7f]

         |  \\[\x01-\x09\x0b\x0c\x0e-\x7f])+)\])\z

• Email addresses

Famous phycisists

(with their birth year) rearrange the letters

13) Beginners were here (1901) – Werner Heisenberg

14) A chairlady fame (1791) – Michael Faraday

15) Awaits on acne (1642)  – Isaac Newton

16) Nettle Binaries(1879) – Albert Einstein

17) I Urea crime (1867) – Marie Curie

18) I agile oil legal (1564) – Galileo Galilei

Famous monsters

Name the film

19 Star Wars: Episode V – The Empire Strikes Back – (The wampa ice creature that attacked Luke)

20 The Thing – (the thing!)

21 Pan’s Labyrinth – (the pale man)

22 Clash of the Titans – (The Kraken)

23 Monsters, Inc – (Randall Boggs)

24 Beowulf  (The sea monster?)

Annual Geek Christmas Quiz – 2015

Films/Sci-Fi

1. What was Luke Skywalker’s name in the original Star Wars screenplay?
2. Who directed the latest Star Wars film – (The Force Awakens)?
3. What colour are the Sith’s light sabers?
4. What year was the film 2001 A space odyssey released?
5. What was the name of the book, written by Philip K Dick, that Blade runner was based on?
6. How long is Harry Potter’s Wand?

 

Taglines – what was the film?

1. In space no-one can hear you scream
2. To boldly go where no man has gone before
3. An adventure 65 million years in the making.
4. It’s Christmas Eve In L.A. And The Party Action’s About To Explode… On The Fortieth Floor!
5. We’re all in it together
6. Nothing On Earth Could Come Between Them

 

Computers

1. What does EEPROM stand for?
2. How many principles are in the Agile Manifesto?
3. What does FORTRAN stand for?
4. What does COBOL stand for?
5. What is Oct 31 in Decimal?
6. What is Moore’s Law?

 

Science

1. What is the name of the largest moon in the solar system?
2. How fast does the ISS travel
3. Cornflakes were invented to cure what?
4. up, down, strange, charm, top, and bottom – what are they all types of?
5. What is the first law of thermodynamics?
6. What are the blocks in Tetris known as?

 

People

1. Who got into a ‘quagmire and botheration’ with mutable state when programming Charles Babbage’s difference engine
2. What was Tony Hoare’s ‘Billion Dollar Mistake’?
3. Kellogg and Rice invented what?
4. What name was the most searched term in the UK in 2015 according to google
5. Who was the first Briton in Space?
6. Who invented the cat flap?

Picture Round

What are the missing country codes?

 

1

2

3

4

5

6

 

Famous RegEx

what is it matching?

 

7) [ -~]

 

8) ^(.)(.)\2\1$

 

9) /^#?([a-f0-9]{6}|[a-f0-9]{3})$/

 

10) /^<([a-z]+)([^<]+)*(?:>(.*)<\/\1>|\s+\/>)$/

 

11) ^(([0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|25[0-5])\.){3}([0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|25[0-5])$

 

12) \A(?:[a-z0-9!#$%&’*+/=?^_`{|}~-]+(?:\.[a-z0-9!#$%&’*+/=?^_`{|}~-]+)*

 |  “(?:[\x01-\x08\x0b\x0c\x0e-\x1f\x21\x23-\x5b\x5d-\x7f]

     |  \\[\x01-\x09\x0b\x0c\x0e-\x7f])*”)

@ (?:(?:[a-z0-9](?:[a-z0-9-]*[a-z0-9])?\.)+[a-z0-9](?:[a-z0-9-]*[a-z0-9])?

 |  \[(?:(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.){3}

      (?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?|[a-z0-9-]*[a-z0-9]:

         (?:[\x01-\x08\x0b\x0c\x0e-\x1f\x21-\x5a\x53-\x7f]

         |  \\[\x01-\x09\x0b\x0c\x0e-\x7f])+)\])\z

 

Famous phycisists

(with their birth year) rearrange the letters

 

13) Beginners were here (1901)

14) A chairlady fame (1791)

15) Awaits on acne (1642)

16) Nettle Binaries(1879)

17) I Urea crime (1867)

18) I agile oil legal (1564)

 

Famous monsters

Name the film

STEM Volunteering at Big Bang Fair 2015

So this year, I decided to apply to become a STEM ambassador. This is a scheme run  Brighton University to encourage those in industry to inspire the next generation into these subjects. The great thing about the STEM Net programme is that they do the DBS checks for you and can facilitate in organising attending events. They also can give advice and training.

My first opportunity came last week when I volunteered to help at the Big Bang Fair SE 2015 in Ardingly.

The event was well attended by primary schools around the south east. It was the perfect day to get going and help with ushering and directing people around the showground. The kids absolutely loved every minute.

The exhibits and workshops were quite diverse. The Accelerator was a blow up structure which you run through and it measures your speed, it took a bit of setting up but was quite simple in the end. The Mary Rose table showed the physics of the ship and why it sank. There were fun stalls like Noisy toys, which showed how a current can produce sounds – even when applied through children! The part I showed children round had a brilliant science fiction show, some great workshops and a rocket science talk.

For anyone wanting to start with volunteering, even without much science knowledge, it’s a great thing to get into. Definitely Looking forward to helping again next year!

Brighton Codebar

Codebar is a Meetup group in Brighton, London and Cambridge for minorities in Tech. The idea is to make coding exciting for people who have not always been encouraged into tech before. The group is mainly for Women or LGBTQ people – those underrepresented in technology. Currently just one in 20 job applicants for new roles in IT are women so events like this and others are springing up to help redress the balance.

The group is every Tuesday evening in various locations. It’s totally free, very friendly and you even get pizza. It is staffed completely by volunteers and various companies give up their office space to host it. There are enough coaches to take you through the tutorials and give lots of advice on coding. Its social but also very useful training.

I was recommended it by a colleague who wondered if I’d be interested. Having worked in IT for quite a while, I was not sure if I should go in as student or coach. However I thought going as student would be a good first step for me as I had not had opportunity to play with javascript much before and I want to get a feel for the tutorials.

Each week I’ve gone I’ve had one-to-one coaching. The expert has sat back patiently not taking over the keyboard but helping explain the exercises and helping with coding. This works really well, coaches are encouraged to not take over and let the student make mistakes and work things out their own way. There is plenty of great advice to coaches such as – ‘assume that anyone you’re teaching has no knowledge but infinite intelligence’ I think many senior programmers would do well to follow this advice as a better way for interacting with new developers.

If you are interested in joining as a coach or student, you need to register on the codebar website. When you turn up, you do need a laptop with wifi connection, you can download the tutorials and get going straight away.

Netduino – 3. Making sounds

(A post I drafted a while ago. Thought I’d better update it!)

A piezo speaker or buzzer of the sort found in small toys and birthday cards can be powered and controlled by the netduino. They can be bought separately very cheaply. You can rip one out and connect it to an output port in series with a resistor.  A variable resistor (potentiometer) is ideal as you can use it as a volume control but for this example a 1k resistor is used.

Piezo speakers run with a small digital input and so are ideal for taking power from the netduino digital ports. By switching the current on and off very fast, the speaker vibrates. The sound produced by the speaker depends on the frequency the output is switched on and off. This is controlled with something called Pulse Width Modulation (PWM).  In our case, the value of the resistor determines the volume.

You will need to connect the speaker to the netduino. In order to create the circuit without soldering, you can use a small breadboard for this along with some leads. You can buy the leads themselves or make your own from an old cat5 cable sliced up. For this project, the negative lead (black) will run to ground terminal on the netduino and the positive lead (red)  runs in series with the resistor to a digital port with Pulse Width Modulation (PWM) enabled. These are ports x,x,x. I used digital port 5.

Now some code to make a small sound. The code for playing frequencies is contained within the speaker class. The main program just plays a scale in a loop until we press the button to stop it.

On the netduino forums there is an example of this setup playing a variety of tunes through a piezo speaker. There’s some nicely written classes there for defining notes and frequencies and also a few recognisable tunes. You would need to piece together some of the code in the thread to make the example work.

http://forums.netduino.com/index.php?/topic/831-music-with-a-piezo-speaker/page__p__6044__hl__piezo__fromsearch__1#entry6044

Video tutorial here:

Update:

I have pushed the code for this on github and implemented the missing classes:

https://github.com/octoberclub/NetduinoDemo/tree/master/Netduino.PiezoTest2

Also changed the class below so it calculates the frequencies for the notes instead of hardcoding them into an Dictionary as in the original post

    using System;
    using Microsoft.SPOT;

    public static class NoteFrequencies
    {
        /// <summary>
        /// Static method to calculate the frequency of a note from its name and octave.
        /// </summary>
        /// <param name="octave">Octave number (0-7)</param>
        /// <param name="note">Note to be found: eg. F#, A, Bb</param>
        /// <returns></returns>
        public static float CalculateFrequency(int octave, string note)
        {
            string noteLC = note.ToLower();
            string[] notes = "c,c#,d,d#,e,f,f#,g,g#,a,a#,b".Split(',');

            // loop through each note until we find the index of the one we want        
            for (int n = 0; n < notes.Length; n++)
            {
                if (notes[n] == noteLC // frequency found for major and sharp notes
                    || (note.Length > 1 && noteLC[1] == 'b' && notes[n + 1][0] == noteLC[0])) // or flat of next note
                {
                    // Multiply initial note by 2 to the power (n / 12) to get correct frequency, 
                    //  (where n is the number of notes above the first note). 
                    //  Then mutiply that value by 2 to go up each octave
                    return (16.35f * (float)System.Math.Pow(2, (n / 12)))
                        * (float)System.Math.Pow(2, octave);
                }
            }
            throw new ArgumentException("No frequency found for note : " + note, note);
        }
    }

The power of the written word

Today, serendipitous events have conspired to help me start writing this blog again.

1) Losing myself in the minutiae of details, when really, I just want to appreciate the bigger picture and help other to do the same.

2) Realising that I have had perhaps the most educational year of my life in terms of working with like-minded & inspirational people and yet I have not blogged about my experience.

3) Reading these posts:

http://erlingwl.wordpress.com/2012/07/23/liberated-devs-dont-blog/

http://www.codinghorror.com/blog/2012/07/but-you-did-not-persuade-me.html

Like Erling, I have passion  for new technology. I often show it, but only in a instant and usually only in conversation or email. Perhaps I am liberated. Perhaps I don’t feel the need to publicise myself.  I often feel a little uncomfortable expressing a hard opinion particularly in public on the web. But I always get excited about technologies or new ideas and that passion should be shared.

If I wrote down some of the things I’m thinking, then perhaps I might come back to it in years to come. Perhaps others might understand where I am coming from. Perhaps I would also discover more about myself in the act of writing my thoughts

So, today marks a new era. I’m planning to start blogging again.

This is more a promise to myself than anything else, but in any case, here are some of the things I’d like to write more about soon:

• NCrunch
• Octopus Deploy
• Approval Tests
• Raspberry Pi
• Netduino
• Code Club
• Git
• TeamCity
• IFTTT
• RoundHousE database deploy
• Fitnesse
• Specflow
• BDD
• TDD
• Approval Tests
• Educational Software
• NoSQL
• AppHarbour
• NUnit Action Attributes
• Functional Programming
• Pomodoro technique
• UI Testing
• Removing dead code
• Logging
• I’m sure there’s more….!

Behaviour-Driven-Development (BDD)

Traditional software releases, agile or not, usually contain the following steps:

1. Specification
2. Development
3. Testing

In a perfect world, the specification enables developers to write a program with the right functionality. The software would be written with no bugs and be delivered to the customer after successful testing.

Unfortunately things go wrong.

• communication problems due to complexity of the problem
• misunderstandings about what the customer asked for
• implicit assumptions about desired behaviour – e.g edge cases, performance etc..
• environmental issues such as external systems not being ready, test data being unavailable or unrealistic
• we may not appreciate the size of the work until we are in the middle of it

The later we discover these problems, the costlier they are to solve.

Specifications
Specifications, no matter how well they are documented and in how much detail, are too often lost in translation. Also, if developers and testers are not involved to suggest simpler alternatives – the solution can become unnecessarily expensive. Traditional system documentation is out-of-date almost as soon as it’s written, whereas agile acceptance tests/specifications by example when used as the basis of integration/unit tests become your system documentation and are up-to-date, or the tests fail.

Development
As a feature is developed, changes very often arise. Customers may not require what they first thought they wanted. Often new features are invented by developers that may cover (in their minds) possible future requirements. So what usually happens is that the specification does not match what the program actually does. How then can we keep the spec in sync with the code?

Testing
Typically, the development-testing cycle is a bottleneck that can seriously delay a project. Testers are lumbered with testing an application they know little about. They have to pick away at original requirements that may not match what the application actually should do. This may mean repeating the same information in further documents used as test scripts.

BDD addresses some of the problems that TDD cannot solve on its own. It involves collaboration between developers, QA, business experts and the customer. The aim is to uncover incorrect assumptions and discover functional gaps before development starts.

It was coined by Dan North in 2003 and has more recently become quite a mainstream idea. Around that time, the term ‘Agile Acceptance Testing’ had pretty much the same goals. However, when people hear the word Testing, it can create the impression that it is something done after coding and has nothing to do with requirements. In fact BDD is all about requirements and so the word Testing can lead to some misunderstanding within this context. BDD prescribes a particular way of wording the expected behaviour through concrete examples or scenarios. This tends to work well in situations such as workflows but not in others such as state transitions or calculations. They may be better described in table format.

BDD allows us to deliver the right software collaboratively. Communication is at the core of this. BDD is definitely not a development methodology whereas TDD is. It is also not so important which tool is used to link specifications to code. What is more important is the focussed discussion about what is required. The tool we use for BDD is nowhere near as important as the process of getting the examples: the collaborative approach to build and refine them; and (hopefully) a common language evolving.

BDD also really feeds nicely into TDD, iteratively guiding it from the outside-in.

Each scenario can be automated against the existing code so that we have living documentation – i.e. Anything changes in either the specs or the code and the business knows about it.

Automating acceptance tests can be quite a headache as they typically are more end-to-end. They might involve some complex setup and configuration before running. In that respect, the BDD tools are not ideal for writing lots of regression tests with. The focus should be on identifying the requirements and endeavouring to prove important scenarios via test fixtures.

Tidying up technical debt using TDD

Where do we start to pay off  technical debt?

One of the problems is the time it takes to release functionality to customers. With each change we need to re-test the product. The QA people are overburdened with manual regression tests.

There’s also the problem of how to redesign some of the code base. We want some sort of check that makes sure that released code is of a consistent quality.

Agile Testing

My experience lies in Automated Testing. I first wrote a unit test around 2001 when Extreme Programming was the new thing. Since then, I’ve discovered many ways of doing things. Some good, some not so good.

Initially I saw automated testing as something you did purely for regression tests. I would jump right in and start making changes to code. Then I’d scratch my head and wonder about all the database setup and context I would need in order to validate my code. It became a maintenance headache.

A common question I came up against was what is the value of something that doesn’t manually test software end to end? I was told the only way a test was meaningful was if it went through the UI. But I’d worked on software that was tested through screens before. The testing tools were based on the idea of automating the pointing and clicking on the screen, then verifying text on the screen. These tests seemed to always fail even though nothing had changed. They were very brittle.

Then came the concept of TDD and unit testing.

Test Driven Development

TDD is a development methodology that aims to catch problems early on.

It is best to catch problems early. It is far cheaper, in terms of time and effort, to fix a problem in development than after it has been released to a customer.

There are many great examples of this in software and also in areas such as car manufacturing, the building industry and space missions.

In TDD, developers write small tests to specify what a unit of code should do. Then they implement the code to satisfy the requirement. The code is tidied up, as they go, without breaking existing functionality.

Instead of trying to do a big design up front, it works iteratively, evolving the code to solve a problem bit-by-bit. That is why it works best with iterative methodolgies such as Agile.

It provides the following benefits:

1. a set of tests that exercise the code and tell us early if something breaks
2. better quality code
   • more maintainable.
   • focussed on a single defined problem
   • modules are inherently less tied together
3. documented functionality that is a true representation of what the code does
4. promotes group ownership – the team collectively own the code and verify it as part of a build

It is important to note, it does not replace good software architecture and domain knowledge.

On its own, TDD will change the way we develop but it will not solve every bug. It also does not guarantee we deliver the right thing. It should be used in conjunction with other good practises.

A common question is how much longer will it take to do TDD? The answer is it depends. There’s a good post on @mikehadlows’s website addressing this. I would say to start with it can take some getting used to. It may take twice as long depending on the problem and experience of the team. Overall it should make things easier – especially as the post development testing cycle tends to add on a lot of release time and is rarely factored into the coding time.

For more information and some real world case studies see:

http://en.wikipedia.org/wiki/Test-driven_development

http://stackoverflow.com/questions/3850876/statistics-of-positive-impact-of-tdd-bdd

http://frazzleddad.blogspot.com/2010/02/case-studies-on-benefits-of-tdd.html

http://biblio.gdinwiddie.com/biblio/StudiesOfTestDrivenDevelopment

Progressive .Net tutorials

I had the pleasure of attending Progressive .Net tutorials last week at skillsmatter. Thanks to my current workplace 15below . The thing I liked best about these sessions is they covered each subject in 3 ½ hours which gave plenty of time to understand some theory, do some exercises and have discussion. On the whole the sessions were really useful and I recommend anyone interested in learning good software practises to look at the website for upcoming talks (plenty are free if you go in evening). Also you can watch the videos of any session from the links.

Information leaves my head as quickly as it enters, so I thought I’d better do a brain dump and summarise what I learnt for future reference.

Day 1 5th Sep

GHERKIN ACCEPTANCE CRITERIA

i.e. specifying requirements as tests.

So we went through some theory with Christian. The following points stood out to me:

• Automate acceptance criteria with stories and a bunch of scenarios showing concrete examples
• Do just enough stories/scenarios for a sprint (i.e. don’t do everything up front). Limit Work in progress
• Examples are good for explaining complexity. We do it every day when talking to people. It’s difficult to explain abstract concepts without examples.
• In order to keep examples up to date, automate them as tests against live code using continuous integration
• Make the examples business readable. E.g They showed a nice dashboard showing progress of specifications etc http://www.speclog.net/
• It is not necessary to replace burndowns and task lists with scenarios but it may be helpful to include a loose link between them (e.g. a task/bug Id referenced in the story title)
• Developed or legacy code is fine to do BDD against, but beware – it will take longer. It is much easier for greenfield projects. We should measure timings against that to get a true idea of the time taken to work in this way.

We then learnt how the Gherkin language can be used to provide scenarios in a formalised manner that is succinct enough to be easily read and tests core business functionality.

We worked through some exercises like the one below (from the presentation slides):

AUTOMATING GHERKIN ACCEPTANCE CRITERIA

In the afternoon, there was some overlap with the first session, but the interesting part was looking at how to integrate the specs with the code. I suggest go to the website www.specflow.org, watch the tutorials, download the plugin and play around. There were some really easy ways to create the fixtures needed to run the scenarios from gherkin feature files. I’m planning to try and use this tool as soon as possible.

Day 2 6th Sep

LOAD TESTING FOR DEVELOPERS

The speaker gave a good talk on how architecture on its own does not solve the problem of scalability. Testing is needed as early as possible as a way of exploring how the application behaves with multiple users and also to prove how it should respond under known loads. There is also a distinction between Load Testing (testing under typical load) and stress testing (seeing how far we can go before breaking it)

Here is the overview of what we did:

http://www.codingthearchitecture.com/2011/08/25/load_testing_for_developers.html

The tools we used to exercise an example application were open source but he explained the UI was very old. Still, it worked and the point of the tutorial was to show the sort of concepts useful for load testing early in a software cycle.

CI TO CONTINUOUS DELIVERY

This was a fun session. The speaker was very enthusiastic about CI and a variety of other topics like TDD coverage and feature branching

Generally the slides showed examples of building and deploying applications using Teamcity (one in less than 7 secs!) and provided the reasons why it is important to have software that is constantly in releasable state.

The core practises were given as follow:

• Continuous Integration
• Configuration Management
•           Dependencies
•           Documentation
•           Environment
•           App Configurations
•           Data
• Tests
•           Unit
•           Integration
•           Functional/Acceptance
•           Performance/Load
•           Penetration

Feature switching vs feature branching was a hot topic.

The interesting part was how software was deployed onto staging, UAT and production. The speaker talked about the following flow that allows the build to check in packages that can be installed automatically on the test server via a build agent on every check in:

Day 3 7th Sep

ASYNC METHODS IN C# 5

Jon Skeet is a very entertaining speaker and covered a complex subject with some enthusiasm.

The first part showed how you would use the C#5 Async CTP library to write asynchronous code without having to write too much boilerplate code. The history of async in C# was described – this is the third attempt. It should result in much cleaner code: e.g.

// code to asynchronously determine the size of the Stack Overflow home pageusing System;
using System.Net;
using System.Threading.Tasks;</pre>
class Program
{
// Caller (block 1)
static void Main()
{
Task<int> sizeTask = DownloadSizeAsync("<a href="http://stackoverflow.com">http://stackoverflow.com</a>");
Console.WriteLine("In Main, after async method call...");
Console.WriteLine("Size: {0}", sizeTask.Result);
}

// Async method (block 2)
static async Task<int> DownloadSizeAsync(string url)
{
var client = new WebClient();
// Awaitable (block 3)
var awaitable = client.DownloadDataTaskAsync(url);

Console.WriteLine("Starting await...");
byte[] data = await awaitable;
Console.WriteLine("Finished awaiting...");

return data.Length;
}
}

In essence 2 keywords have been introduced to the compiler – async and await. async explicitly sets up your method as something that is intended to run asynchronously. await informs the compiler that the code following this line (called a continuation) should run after the async method comes back. Thus the compiler hold on to the state and but knows not to wait on the thread.

The second part was a little scary. Bit by bit, the speaker implemented the async functionality using .Net 4 in order to get an understanding of what is going on under the hood. What we could see is that the compiler is making use of delegates and iteration blocks to decide whether to carry on synchronously (if the async task is already completed) or keep the state and hand back control to the thread pool. The full blog posts are here http://msmvps.com/blogs/jon_skeet/archive/tags/Eduasync/default.aspx

YOU THINK YOU KNOW AGILE?

This was a slide show powerpoint presentation. I’ve downloaded the slides – they pretty much reflect the content of the talk..

In summary, the following points were discussed:

· Agile Manifesto

· Concepts

· Team

• Developer
• Tester
• Business Analyst
• Team Lead
• Architect
• Product Owner

· Methodologies

o Scrum

o XP

o Kanban

I think this talk would be really useful if we had had more discussion of some of the pain points in the process and how to deal with the customer who wants a project plan up front. In the break he touched on this, giving example of a scrum master who presented a GANT chart to the client while maintaining sprints internally with story points and factoring in slack.