Every time a child says, 'I don't believe in fairies,' there is a fairy somewhere that falls down dead.

Peter Pan is one of my favourite stories and the title of this post is one of the most iconic phrases to come out of the book.

It's at the beginning of the book when Wendy and Peter are speaking. Peter explains that when the first baby laughed, its laughter fell and broke into a thousand pieces. This big breakup of laughter means that there "ought to be one fairy for every boy and girl". Wendy notices that Peter said should and questions him.
"Ought to be? Isn't there?"
"Every time a child says, 'I don't believe in fairies,' there is a fairy somewhere that falls down dead." Peter replies.

The same can almost be said about testers when a developers don't check their code works. I don't mean a tester will die every time but a small part of their resolve dies everytime. If its not a testers resolve that dies, it may be real people that die. This may sound quite extreme but its not really.

Since the begiing of the Agile movement there has been a great movement to get the quality of software a lot higher. Aside from all the other major benefits of using scrum and XP, people have noticed the quality of software being delivered go up. They have done it by employing things that make the process more effective. Not all of these processes are efficient but they are extremely effective.

Testers resolve only dies when they feel that something could easily have been caught by the developers being effective at their job. Being efficient can lead to bugs because we are trying to develop a feature within a set timeframe which is normally slightly shorter than it should be.  This is not all doom and gloom, there are bugs that testers love to find. Remember the rule for testing that if a test case is good it will find a bug but remember that testers are not there to make sure that you are doing your job properly. They are there to make sure that its fit for purpose!

When developing software always remember that you are killing your testers really slowly  when you are not doing your job properly!

"To die will be an awfully big adventure." Peter Pan 

This is something that every tester, from load tester to functional tester to security tester, loves to do. Make an application fall to it knees because it we managed to find some big hole. Making an application die is an adventure in many many ways. From going through the process of breaking it, to working out the cause of the breakage.


I have just watched Peter Pan for the umpteenth time and it got me thinking about my profession. Treat your testers like you would Peter Pan and they will be a lot more effective in finding those elusive bugs!

Designing and Testing with Behaviours rather than requirements

A few months ago I decided that I wanted to learn something new. I decided that I would have a go on the Google App Engine, learning Python and jQuery. I decided that I would start working on something that would be useful, at least for me, and go from there. I also thought that I would give Behaviour Driven Development a try

I decided that I would work on a project management application. So the first thing I needed was a way to store my backlog and visually see where items were on the stack.

Since I have a stack on bits of paper and want to do this by describing my behaviors for each of my requirements I need a way to describe them that I can easily translate into a test. I went looking through all the different BDD Frameworks (NBehave, Behaviour, JBehave, RBehave,StoryQ, and many many more!) to look for the common phrases and it came back with the phrase that I think is brilliant. It flows off the tongue so easily that getting product owners involved to write them can make an agile project work like clockwork.

The phrase is below. NOTE: The bold items make the main phrase up and the italics make it more readable.

As a product owner
I want functionality
so that something is done
with Scenarios

Scenario 1:
Given start point
When do something
Then expections will be met
.
.
.
Scenario n:
.
.
.

This can easily be coded into different languages and in some of the languages the natural language above is all that is needed but just a little tweaking to get the functions calls sorted. If you are a Selenium nut like me you could even drive with something like FitNesse. Gojko Adzic has explained it really well on his blog so suggest you have a look there.

The other plus point for BDD in Agile environments is its ability to change the BDD test very quickly if the product owner changes their mind. And since product owners change their minds every time they have a cup of tea, and in the UK it can be very often, you need to be able to keep your tests up to date.

Testing through the Credit Crunch - Part 2 - Test Driven Development

In the last post of this series I discussed briefly about Technical Debt and how Test Driven Development can help in dropping the debt and dropping the amount of interest gained over the life of the product.

Test Driven Development is the concept that you write your tests before you write your code. Once your code is finished you refactor with the safety that your newly created test will prevent any stupid bugs that you could have introduced. It's what the TDD community call Red-Green-Refactor. Now to most people writing tests first sounds stupid, "How do you know what your code is going to do until you have finished coding it?"
My retort tends to be "You know what you are expecting back from the call. Your test needs to be really small and since an Assert is a test, Assert what you are expecting your method to return! Image that your code exists and test against it." Below is an example of a small test and when writing tests we should try keep them as small as we physically can.

[Test]
public void creditcrunch_Test(){
int FutureTechnicalDebt = 100;
Assert.LessThan(FutureTechnicalDebt,TechnicalDebt.Current);
}

So we know that we need tests first to give us a good safety net for writing our code.In Technical Debt terms we have spent a little less to create/run and report on the test and we prevent anyone else breaking our code. Cost-- and Interest-- which is what we want. Running the test above will fail because there is no code to run it against. Write some code to make it pass if you have the time.

The other reason why developers are starting to like TDD, other than the removal of the ear ache that testers would give them about throwaway builds, is that challenges them to think about the interface into their new object. We have all sat down with the keyboard in front of us, tea/coffee next to us and found that someone has changed the interface your were developing against! Queue the expletives! $*@%*$£ !@)@)£)&! Luckily for us we have good Test Driven Developers who have have discussed the interface and we by proxy prevented interest being added to our debt. Interest--! Communication is key in Test Driven Developments, especially when it comes to interfaces because there may be some integration bugs that will creep in without you realising!

Knowing what the Interface is going to look like is has another major benefit. Mocks and stubs! If we know what the interface to an assembly is and how its going to react we can write tests to test our code and when it needs to speak to the other assembly, which may not have been created yet or makes our tests run slowly like accessing a database or filesystem, we can return the results back that we want our code to handle using one of them. This could be exceptions,dodgy data or good data. Testing those code paths means we can increase our code coverage therefore increasing the size of our safety net! It will also mean that our tests run a lot quicker because we don't have to interact with slow drives or have anyone elses tests interfere with our data. Cost-- and Interest--.

So by creating this safety net we have prevented stupid mistakes creeping into our code. Its these stupid mistakes that could cost our team/company a lot of money. Since companies don't have much money it could mean your job!

The graph below shows how by doing the, what I call, simple things we have brought down the technical debt that we could potentially owe. NOTE: The values used are just arbitary values I found on the internet with a little searching.

In the next post in the series I will discuss Virtualization and what the it can mean to you as  a tester!

.Net Gem - How to Unit Test Internal Methods

I have recently started redoing unit tests for bit of code at work and came across a internal methods and classes that needed to be tested.

This posed a question of: how do I access the internal methods and classes to test them properly from an external assembly?

I found this little gem that a lot of the developers where I work had not heard of, this doesn't mean that its not common knowledge but thought I would share it a little more.

I have put a scenario below of how it might work.

Being a good TDD developer you decide that you want to write your unit tests for an internal method. You create your .Net Class Library structure so you know what your tests need to call to do your asserts. It may looks something like the image below.

So now you want to start writing your tests and notice that your intellisense is not bringing up your internal class. So what do you do next?

Open the AssemblyInfo.cs file that is in your Properties folder. Add the line [assembly:InternalsVisibleTo("Unit.Tests")] somewhere near the top.

Now your Internal Classes and methods are only visible to Unit.Tests assembly.

Your start writing your unit tests and intellisense should be playing Mr. Nice Guy and we should see something like below.

I hope that it has been useful!