markhneedham/blog huggingface dataset:
TDD: Consistent test structure
Date: 2010-03-24 06:53:55

While pairing with http://foldingair.blogspot.com/[Damian] we came across the fairly common situation where we'd written two different tests - one to handle the positive case and one the negative case.

While tidying up the tests after we'd got them passing we noticed that the test structure wasn't exactly the same. The two tests looked a bit like this:

[source,csharp]
----

[Test]
public void ShouldSetSomethingIfWeHaveAFoo()
{
	var aFoo = FooBuilder.Build.WithBar("bar").WithBaz("baz").AFoo();

	// some random setup
	// some stubs/expectations

	var result = new Controller(...).Submit(aFoo);

	Assert.That(result.HasFoo, Is.True);
}
----

[source,csharp]
----

[Test]
public void ShouldNotSetSomethingIfWeDoNotHaveAFoo()
{
	// some random setup
	// some stubs/expectations

	var result = new Controller(...).Submit(null);

	Assert.That(result.HasFoo, Is.False);
}
----

There isn't a great deal of difference between these two bits of code but the structure of the test isn't the same because I inlined the 'aFoo' variable in the second test.

Damian pointed out that if we were just glancing at the tests in the future it would be much easier for us if the structure was exactly the same. This would mean that we would immediately be able to identify what the test was supposed to be doing and why.

In this contrived example we would just need to pull out the 'null' into a descriptive variable:

[source,csharp]
----

[Test]
public void ShouldNotSetSomethingIfWeDoNotHaveAFoo()
{
	var noFoo = null;

	// some random setup
	// some stubs/expectations

	var result = new Controller(...).Submit(noFoo);

	Assert.That(result.HasFoo, Is.False);
}
----

Although this is a simple example I've been trying to follow this guideline wherever possible and my tests now tend to have the following structure:

[source,csharp]
----

[Test]
public void ShouldShowTheStructureOfMarksTests()
{
	// The test data that's important for the test
	
	// Less important test data

	// Expectation/Stub setup

	// Call to object under test

	// Assertions
}
----

As a neat side effect I've also noticed that it seems to be easier to spot duplication that we can possibly extract with this approach as well.
Preventing systematic errors: An example
Date: 2010-03-13 23:26:23

James Shore has http://jamesshore.com/Blog/Alternatives-to-Acceptance-Testing.html[an interesting recent blog post where he describes some alternatives to over reliance on acceptance testing] and one of the ideas that he describes is fixing the process whenever a bug is found in exploratory testing.

He describes two ways of preventing bugs from making it through to exploratory testing:

* Make the bug impossible
* Catch the bug automatically

____
Sometimes we can prevent defects by changing the design of our system so that type of defect is impossible. For example, if find a defect that's caused by mismatch between UI field lengths and database field lengths, we might change our build to automatically generate the UI field lengths from database metadata. When we can't make defects impossible, we try to catch them automatically, typically by improving our build or test suite. For example, we might create a test that looks at all of our UI field lengths and checks each one against the database.
____

We had an example of the latter this week around some code which loads rules out of a database and then tries to map those rules to classes in the code through use of reflection.

For example a rule might refer to a specific property on an object so if the name of the property in the database doesn't match the name of the property on the object then we end up with an exception.

This hadn't happened before because we hadn't been making many changes to the names of those properties and when we did people generally remembered that if they changed the object then they should change the database script as well.

Having that sort of manual step always seems a bit risky to me since it's prone to human error, so having worked out what was going on we wrote a couple of integration tests to ensure that every property in the database matched up with those in the code.

We couldn't completely eliminate this type of bug in this case because the business wanted to have the rules configurable on the fly via the database.

It perhaps seems quite obvious that we should look to write these types of tests to shorten the feedback loop and allow us to catch problems earlier than we otherwise would but it's easy to forget to do this so James' post provides a good reminder!
A reminder of the usefulness of Git
Date: 2010-03-14 00:45:34

Despite the fact that none of the projects that I've worked on have used http://git-scm.com/[Git] or http://mercurial.selenic.com/[Mercurial] as the team's main repository I keep forgetting how useful those tools can be even if they're just being used locally.

I ran into a problem when trying to work out why a Rhino Mocks expectation wasn't working as I expected last week having refactored a bit of code to include a constructor.

I wanted to include the Rhino Mocks source code in our solution before and after the refactoring and step through the code to see what was different in the way the expectations were being setup.

My initial thought was that I could just check out the repository again in another folder and then include the Rhino Mocks source code there and step through it but unfortunately we have all the projects set up to deploy to IIS so Visual Studio wanted me to adjust all those settings in order to load the solution in the new checkout location.

I probably could have gone and turned off that setting but it seemed a bit too much effort and I realised that I could easily use Git to help me solve the problem.

I took a patch of the changes I'd made and then reverted the code before checking it into a local Git repository.

I updated the solution to include the http://www.ayende.com/projects/rhino-mocks.aspx[Rhino Mocks] code and then created a branch called 'refactoringChanges' so that I could then apply the patch that I'd created with my changes.

It was then really easy to switch back between the two branches and see the differences in the way that the Rhino Mocks was working internally.

The actual problem eventually turned out to be the way that the code calls Castle DynamicProxy but I didn't get the chance to look further into it - we had learnt enough to know how we could get around the problem.

I'm in the process of including the source code for all the 3rd party libraries that we use in the solution on a separate Git branch that I can switch to when I want to debug through that code.

Sometimes I end up having to close down Visual Studio and re-open the solution when I switch to and from that branch but apart from that it seems to work reasonably well so far.
Defensive Programming and the UI
Date: 2010-03-22 23:42:02

A few weeks ago I was looking at quite an interesting bug in our system which initially didn't seem possible.

On one of our screens we have some questions that the user fills in which read a bit like this:

* Do you have a foo?
 ** Is your foo an approved foo?
 ** Is your foo special?

i.e. you would only see the 2nd and 3rd questions on the screen if you answered yes to the first question.

However, if you went to the next page on the form having answered 'Yes' to the first question and then came back to this page and changed your answer to the first question to 'No' then when the data got submitted to the server the answers to the other two questions would still be posted.

We were therefore ending up with a request with the following values submitted:

[source,text]
----

hasFoo		"No"
approvedFoo 	"Yes"
specialFoo	"Yes"
----

Later on in the application we had some logic which decided what to do with the user request and this one was erroneously being approved because we hadn't catered for the condition where the first question was answered 'No' and the other questions had 'Yes' values.

In theory we should have written some client side code to reset the optional questions if the first one was answered 'No' but even then it's still possible to post whatever data you want to the server if you try hard enough.

Given that we need to behave in a somewhat defensive way somewhere on the server.

My initial thinking was that perhaps we should change the logic to handle this scenario but talking through the problem with http://mikewagg.blogspot.com/[Mike] he pointed out that it would make more sense to fix the data earlier in the chain.

I ended up writing some code in the controller to change the latter two fields to 'No' if the answer to the first question was 'No'. We're not really using custom binders on the project otherwise I think it would be the type of logic that would go in there.

Overall I'm no really a fan of defensive programming in general because it often seems to lead to over complicated code but in the case of user input it does make sense and the general guideline seems to be to *fix any logically invalid values as close to the entry point of our application as possible*.
Selenium, Firefox and HTTPS pages
Date: 2010-03-25 08:09:26

A fairly common scenario that we come across when building automated test suites using Selenium is the need to get past the security exception that Firefox pops up when you try to access a self signed HTTPS page.

Luckily there is quite a cool plugin for Firefox called 'https://addons.mozilla.org/en-US/firefox/addon/10246[Remember Certificate Exception]' which automatically clicks through the exception and allows the automated tests to keep running and not get stuck on the certificate exception page.

One other thing to note is that if the first time you hit a HTTPS page is on a HTTP POST then the automated test will still get stuck because after the plugin has accepted the certificate exception it will try to refresh the page which leads to the 'Do you want to resend the data' pop up.

We've previously got around this by writing a script using http://www.autoitscript.com/autoit3/index.shtml[AutoIt] which waits for that specific pop up and then 'presses the spacebar' but another way is to ensure that you hit a HTTPS page with a GET request at the beginning of the build so that the certificate exception is accepted for the rest of the test run.

To use the plugin in the build we need to add it to the Firefox profile that we use to run the build.

In Windows you need to run this command (having first ensured that all instances of Firefox are closed):

[source,text]
----

firefox.exe --ProfileManager
----

We then need to create a profile which points to the '/path/to/selenium/profile' directory that we will use when launching Selenium Server. There is a much more detailed description of how to do that on http://girliemangalo.wordpress.com/2009/02/05/creating-firefox-profile-for-your-selenium-rc-tests/[this blog post].

After that we need to launch Firefox with that profile and then add the plugin to the profile.

Having done that we need to tell Selenium Server to use that profile whenever it runs any tests which can be done like so:

[source,text]
----

java -jar selenium-server.jar -firefoxProfileTemplate /path/to/selenium/profile
----
Coding: Another outside in example
Date: 2010-04-18 22:46:46

I've written before about http://www.markhneedham.com/blog/2010/03/02/riskiest-thing-first-vs-outside-in-development/[my thoughts on outside in development] and we came across another example last week where we made our life difficult by not initially following this approach.

The rough design of what we were working on looked like this:

image::{{<siteurl>}}/uploads/2010/04/outsideIn1.gif[outsideIn1.gif,410]

My pair and I were working on the code to do the calculations and we deliberately chose not to drive the functionality from the UI because the other pair were reworking all our validation code and we didn't want to step on each others toes.

We therefore started driving the code directly from the individual calculations and decided to create an object to represent each of the types of calculation. It worked quite well for all but one of the calculation classes, 'Calculation3, which became increasingly complicated as we added more test cases.

At this stage we http://www.markhneedham.com/blog/2008/11/04/pair-programming-benefits-of-the-pair-switch-mid-story/[rotated pairs] and still unable to see a way to simplify 'Calculation3' we decided to try and drive it from the object which would actually make use of it.

As http://twitter.com/darrenhobbs/statuses/12305120777[Darren Hobbs pointed out] in another discussion:

____
Don't design an API. Write the code that you'd want to be able to write to use your API.
____

In this case it became clear that the missing object which could drive out the Calculation objects was a 'Calculator':

image::{{<siteurl>}}/uploads/2010/04/outsideIn2.gif[outsideIn2.gif,410]

We started writing tests for the calculator and initially it didn't seem to make that much difference - the design of nearly all the individual 'Calculation' objects remained the same.

However, once we got to the tests which would drive out the functionality currently in 'Calculation3' it became clear that we had actually got 3 objects inside 1 and that what we really needed in this case was an orchestrating class which could delegate down to small objects to do the calculations.

image::{{<siteurl>}}/uploads/2010/04/outsideIn3.gif[outsideIn3.gif,455]

The most interesting thing about this situation for me is that I often do drive code from the outside in and I've even http://www.markhneedham.com/blog/2009/12/19/coding-an-outside-in-observation[previously written about the benefits of doing so] but in this context I got it wrong and it was a slightly painful lesson!
Late integration: Some thoughts
Date: 2010-04-18 21:19:23

John Daniels has http://jd-syntropy.blogspot.com/2010/03/why-you-should-start-with-end-to-end.html[an interesting post summarising GOOSgaggle], an event run a few weeks ago where people met up to talk about the ideas in 'http://www.amazon.co.uk/Growing-Object-Oriented-Software-Guided-Signature/dp/0321503627/ref=sr_1_1?ie=UTF8&s=books&qid=1271313406&sr=8-1[Growing Object Oriented Software, Guided by Tests]'.

It's an interesting post and towards the end he states the following:

____
Given these two compelling justifications for starting with end-to-end tests, why is it that many people apparently don't start there? We came up with two possibilities, although there may be many others:

*So rather than taking the correct -- and brave -- option of loudly declaring progress on your project to be blocked, you restrict yourself to creating those parts of the system that are within your control.*
http://www.amazon.co.uk/Fifth-Discipline-Peter-M-Senge/dp/1905211201/ref=sr_1_1?ie=UTF8&s=books&qid=1271619479&sr=8-1[systems thinking]*we didn't have sufficient leverage to change the system*
____
Listening to your tests: An example
Date: 2010-04-27 22:34:22

I was recently reading a blog post by Esko Luontola where he talks about http://blog.orfjackal.net/2010/04/direct-and-indirect-effects-of-tdd.html[the direct and indirect effects of TDD] and one particularly interesting point he makes is that driving our code with a TDD approach helps to amplify the problems caused by writing bad code.

____
if the code is not maintainable, it will be hard to change. Also if the code is not testable, it will be hard to write tests for it. If the code would not be written iteratively and no tests would be written for it, life would be much easier to the developer. In other words, TDD increases the pain caused by bad code, because it's not possible to avoid changing the code, nor avoid writing tests for it.
____

This is something Steve Freeman and Nat Pryce talk about in http://www.growing-object-oriented-software.com/[their book] and we recently had an example of this which really stemmed from a http://www.markhneedham.com/blog/2010/04/18/coding-another-outside-in-example/[failure to drive this particular piece of code from the outside in].

We'd reached the stage where one object was taking in 8 different parameters in the constructor and then only used 2 of them in any one path through the code.

The code was pretty bad but it was even more noticeable how much of a mess we'd made when we had to write a new test.

This is a rough example of what the test fixture had begun to look like:

[source,csharp]
----

[TestFixture]
public class BadObjectTests
{
	private double parameter1 = 0.10;
	private double parameter2 = 0.20;
	private double parameter3 = 0.30

	[Test]
	public void ATestGoneABitWrong()
	{
		var badObject = CreateBadObject();
		var result = badObject.CalculateSomething()

		Assert.That(result, Is.EqualTo(parameter1));
	}

	private BadObject CreateBadObject()
	{
		return new BadObject(parameter1, parameter2, parameter3...);
	}
}
----

As a general guideline it's good if we're able to keep the context of a test all in one place but since the 'BadObject' had become increasingly difficult to construct we'd pulled that out into another method and extracted all its parameters as fields in the test fixture.

The alternative was to have all 8 parameters created in each test and then construct the 'BadObject' each time and in retrospect that would actually have made it more obvious that we were doing something wrong.

With that second approach we would undoubtably start http://blog.iancartwright.com/2009/04/test-code-is-just-code.html[copy/pasting tests] which would provide another signal that we need to look at the design of the code and make it easier to test.

In this case the solution was to create several smaller objects which actually used all the parameters being passed in. I think we ended up with around 4 objects instead of 1 and each had simple tests that were easy to write.
Functional C#: Using custom delegates to encapsulate Funcs
Date: 2010-04-17 12:16:46

One of the problems that I've frequently run into when writing C# code in a more functional way is that we can often end up with 'Funcs' all over the place which don't really describe what concept they're encapsulating.

We had some code similar to this where it wasn't entirely obvious what the Func being stored in the dictionary was actually doing:

[source,csharp]
----

public class Calculator
{
	private Dictionary<string, Func<double, double, double>> lookups = new Dictionary<string, Func<double, double, double>>();

	public Blah()
	{
		lookups.Add("key", (input1, input2) => (input1 * 0.1) / input2);
	}
	...
}
----

https://twitter.com/christianralph[Christian] pointed out that we can create a named delegate (something I had completely forgotten!) so that it's a bit more obvious what exactly we're storing in the dictionary just by looking at the code.

We'd then end up with this code:

[source,csharp]
----

public class Calculator
{
	private delegate double PremiumCalculation(double input1, double input2);

	private Dictionary<string, PremiumCalculation> lookups = new Dictionary<string, PremiumCalculation >();

	public Calculator()
	{
		lookups.Add("key", (input1, input2) => (input1 * 0.1) / input2);
	}
	...
}
----

Now it's pretty clear from just reading the declaration of 'lookups' what it's being used for without needing to go further into the code to understand that.

This is just a simple example but the problem becomes more obvious the more angle brackets we end up with in our dictionary definition and pulling those Funcs out makes the code much easier to understand.
C#: Java-ish enums
Date: 2010-04-17 10:33:16

We've been writing quite a bit of code on my current project trying to encapsulate user selected values from drop down menus where we then want to go and look up something in another system based on the value that they select.

Essentially we have the need for some of the things that a Java Enum would give us but which a C# one doesn't!

Right now we have several classes similar to the following in our code base to achieve this:

[source,csharp]
----

public class CustomerType
{
    public static readonly CustomerType Good = new CustomerType("Good", "GoodKey");
    public static readonly CustomerType Bad = new CustomerType("Bad", "BadKey");

    private readonly string displayValue;
    private readonly string key;
    private static readonly CustomerType[] all = new[] { Good, Bad };

    private CustomerType(string displayValue, string key)
    {
        this.displayValue = displayValue;
        this.key = key;
    }

    public static CustomerType From(string customerType)
    {
        return all.First(c => c.displayValue == customerType);
    }

    public static string[] Values
    {
        get { return all.Select(c => c.DisplayValue).ToArray(); }
    }

    public string DisplayValue
    {
        get { return displayValue; }
    }

    public string Key
    {
        get { return key; }
    }
}
----

To get values to display in drop downs on the screen we call the following property in our controllers:

[source,csharp]
----

CustomerType.Values
----

And to map from user input to our type we do this:

[source,csharp]
----

CustomerType.From("Good")
----

Right now that will blow up if you trying to parse a value that doesn't have an instance associated with it.

https://twitter.com/christianralph[Christian] came up with the idea of storing each of the public static fields in an array and then using 'First' inside  the 'From' method to select the one that we want.

We previously had a somewhat over complicated dictionary with the display value as the key and type as the value and looked it up that way.

So far this does all that we need to do and the only annoying thing is that if we add a new instance then we need to manually add it to the 'all' array.

An alternative would be to do that using reflection which I think would work but it's simple enough like this so we haven't taken that approach yet.