DDD Geek Dinner

After Developer Day, there was a geek dinner, which was very well attended. I sat with some people who I've met at London geek dinners, and met at previous DDDs. I noticed that during the day I spoke mainly to people I knew already, rather than talking to new people. At the first one, I didn't know anybody, so it wasn't an issue. On one hand, it's great that I'm getting to know some good people better, but on the other hand, I could be missing out on meeting even more good people.

I did see Jean, who I used to work with. Hadn't seen him for a while, so it was good to catch up. I hung around with Matt, who came to the last Sussex geek dinner. I didn't get to speak to him much at the SGD, as we sat too far apart, so it was good to spend time with him.

At the geek dinner, we discussed the seminars in the day. The session on unit testing GUIs was discussed the most. On one hand, it was great that Richard Fennell stepped in to replace the missing speaker with only 6 minutes notice. Richard was a good presenter though; he was entertaining and easy to listen to, and it was an enjoyable session. On the other hand, the method he chose to test GUI code didn't seem to be that robust. To be fair, he did say that it was experimental, and that it was a work in progress, but we concluded that the fundamental approach was wrong.

From memory, the idea was that a method in the production code is decorated with a custom attribute that has (I think) two parameters; a string containing the method name of the unit test that runs it, and a parameter containing the expected result. The test runner used reflection to iterate through each method containing the attribute in the production assembly, and call it's associated test.

I can see why using reflection is a good idea, but I don't think having the test result in the actual code is that helpful. If you want to add more tests, then one would have to change the production code, not the test code. Also, the test name being a string is weakly-typed, and shouldn't be in the production code. If reflection is to be used, I would prefer to see the test code contain the name of the method to test and the expected output, which would leave the production code with no test droppings, and mean that extra tests could be added without changing the code. [This is only a theory, and Richard may have tried this and it didn't work. I haven't tried it myself, and I don't like being too harsh without knowing the full story.]

The conversation turned to test driven development, which four of the five talking use and were in favour of, and one who hadn't tried it yet. The four of us did get rather heated in our insistence that the remaining one should at least try it.

I didn't get the name of one of the guys I was sitting near. He came from way up north, worked for BT and looked like James Nesbitt. Anyone know who he is?

[Tags: ]
22 June 2006