I've attended a few coding dojos where the MineSweeper Kata was used. It has been dojos with both experienced TDD practitioners and TDD beginners. The interesting thing is that both types of dojos have resulted in the same behavior.
The first thing that typically happens is that the group creates a test and implementation for an empty mine field. From here a natural continuation is to add a test for a one by one sized mine field with no mines. At this point there are a few different ways we can go. We can add more mine fields, mine fields of different sizes or we can add mines to the mine field. Each of these paths adds complexity to the solution. What have happened in all the dojos I've attended is that mines are added before one (or sometimes both) of the other complexities.
Before adding mines the code have been very much focused on parsing input but once mines are added we need a good internal representation and a sweeper algorithm to produce the correct output. What I've seen at this point is huge refactoring steps that are hard to complete and the progress of the solution is brought to a halt. I think this happens because the group is so eager to get a complete algorithm so they forget to makes small steps and concentrate on finishing one part (i.e. one dimension of complexity) before moving on to the next one.
But does it have to be this way? I think not. What have happened at the dojos I've attended is that the group every time have started writing end-to-end tests; One input should result in one output. And the group have stayed focused on this even when recognizing the need for a separate parser object and so on. The group have forgotten that they can stub certain parts in order to add functionality in smaller steps and making refactoring possible.
So I think the lessoned learned is that sometimes the best thing is not to start writing separate tests for separate objects (which might happen when the need for a parser is recognized) but rather to stub the parser in order to continue work on the feature you want to add. I think this sounds like the obvious thing to do but still I've seen the same behavior in multiple dojos with both experienced and novices so I guess it is easy to get carried away. But whenever refactoring feels painful you should probably stop what you're doing, take a step back and look at the situation and make sure you're doing the right thing. There might be a less painful way forward that you're missing.
Yesterday a number of my friends had organized a "reunion farewell party". Reunion since many of the guys had not seen each other for several years. Preparing for the party we had a lot of discussions on what would happen because we expected it to get pretty wild. That was when it struck me that a great party is like an Open Space:
There is no point in analyzing what is going to happen more than that... I only feel slightly disturbed just because of the fact that I'm comparing a party with an open space session...
Yesterday the Swedish chapter of ALT.NET held its second unconference. It all started with six lightning talks (of which I held one) followed by an opens space session. It was a great experience to meet so many dedicated developers at once. And even though an unconference tries to be a single long coffee break (since most interesting conversations at a regular conference typically happens during the breaks) it was during the breaks I had the most stimulating conversations.
My lightning talk was on "should we not be mocking" where I talked about the good and bad things that might happen if you're using mock objects and/or mock frameworks. Other talks covered MSpec, OpenTK, db4o and continuous integration (CI). A funny quote from the CI-session is "you can argument against the SOLID principles and TDD but you can't argue against CI".
The open sessions I attended covered TDD of WPF applications, Conventions vs configurations and working with legacy code where CloneDetective was mentioned. I also facilitated an open session on BDD without BDD frameworks. The day ended with a session where we discussed what ALT.NET should be doing. I'm looking forward to see what is going to happen with the "mentor list" that was mentioned.
Last June I presented a link where P&P showed off their fancy office. Now there is a new film with a budget version from the Visual Studio Team Architect team. Probably more realistic so it serves as good inspiration too I think.
I think the most interesting thing about the clip is that almost all team members previously had offices with windows and bad experience with co-location but once co-located with the feature team they all liked it.
If you've read your Scrum literature you'll definitely heard of pigs and chickens. Ade Miller however has identified a few behaviors that you might see in your team that are bad or really bad. And just for the fun of it he came up with a number of animals to represent the different behaviors. The "new" animals in the Scrum farm are:
Yesterday I met with a few former colleagues for the last time. We've met for a few hours three times discussing how to start with TDD and then continuing with BDD. We have had several long discussion on why you benefit from using BDD and how to overcome a number of common mistakes made by BDD novices. It has been vary interesting and I want to share a few of the things we've talked about.
For example we talked about the economics of BDD. The very first time you start using BDD you'll probably spend a lot of extra time to complete your first release as compared to not using BDD (and probably not writing any unit tests either). So how do you motivate this extra cost? First of all I think we can all agree that the behavior driven code will have less defects. This means less time you have to work for free (to fix defects) and you can also focus more on your next project making more money there since you're less interrupted with bugs in the old code. Defects will also typically be found earlier and defects found early when you're still working on the code are fixed faster (i.e. less cost). Second, when the customer wants new features you will probably be able to add new features more quickly with all the test in place than without them. But you still ask for the same money as before so you make a larger profit on all additions. All in all tis should make your software more profitable over time.
Other than economic incitements I think the fact that you as a developer will know if a change breaks the code and not just guess is a great improvement on working conditions. And the fact that you know you're releasing high quality code (instead of hoping you do that) should be enough for every developer to jump on the BDD train...
We've also had long discussion on how to test drive GUIs but I'll cover that again in a future post coming in a few days.
The relocation trip was interesting. Half an hour before we were scheduled to land in Amsterdam we got redirected to Brussels due to this. A quarter of an hour later we started to descend fast in order to land at Amsterdam after all. So we made our connection flight as scheduled.
Regarding traveling with children we have so far made two important observations. Having a seat for the child where you put a car seat is valuable. He slept in the comfort of his car seat for long periods. And jet-lag can be defined as "parents want to sleep and children are hyper active in the middle of the night".
Agile (and especially Scrum) is very hyped in the software industry at the moment. And I think it is because of the hype that one of the most common questions I hear from people that want to start being agile is "what tools are there to help me?". First of all I think many tool seekers forget to ask them self why they want a tool. Because most teams don't need fancy tools. Actually teams not using fancy tools tend to perform better in my experience. Teams with fancy tools tend to spend a lot of time updating stuff in their tool and less time communicating. I guess that is why the agile manifesto says "Individuals and interactions over processes and tools".
This does not mean we should avoid tools. Sometimes tools are helpful and even necessary to a team. Personally I recommend each team I've worked with to try low-tech tools like post-its and white-board at least one iteration before sticking to a tool. Most teams tend to stick with the low-tech... But if you want to try different tools out then Mike Cohn has compiled a list of tools to help you out.
You know you're a geek when you get excited over the fact the the epoch time will pass 1234567890 tonight (when this post is published). What did you do during this event?
When I last wrote about TDD and GUI I was talking quite vaguely about how TDD of GUIs can work. Since then I've thought more on the practical details and by chance the book I was reading at the time (Testdriven by Lasse Koskela) covered this topic. Inspired by that book I've done a few experiments.
First of all we must decide on what we want to test in the GUI. Usability can never be tested only by applying TDD/BDD. So we don't want to test the looks of the GUI. We should test the functionality of the GUI. There is also two types of graphical components we will be testing. There are user controls where we want to test that certain pixels turn out the way we want and there are other types of graphical components.
Let's first look at graphical components where we actually want to check pixel colors. What could this be? Well, it could be a custom graph component or a progress bar. Something where we easily can know from how we setup the test that certain pixels will be of a certain color. To test this we should render the user control to an in-memory bitmap and check the color. Using WPF this is pretty easy using the Render method. Using WinForms we have to use different methods depending on if it is a form or control we're testing. The reason forms are different is that depending on the layout it can be impossible to know the exact offset that should be used so the same method as used for controls cannot be used. On the other hand you should probably not test complete forms by drawing them to a bitmap anyway...
1: public void PaintControl(Control control, Bitmap b)
3: Point offset = GetClientOffset(control);
4: foreach (Control c in control.Controls)
6: c.DrawToBitmap(b, new Rectangle(new Point(offset.X + c.Location.X, offset.Y + c.Location.Y), c.Size));
7: PaintControl(c, b);
The offset code would not be needed if we can use the protected InvokePaint method.
So what about all controls where exact pixel match is not needed, what should we test? Well we can always test relative positioning if it makes sense. Things like "the OK button is always above all other buttons" could be tested if we find that useful. Other than that we should focus on testing that the functionality of the user interface is correct. In order to do this and to make our GUI easily tested I think the MVC (Model-View-Controller) pattern is a great candidate. And probably the best is the variant called MVP (Model-View-Presenter) with a passive view. The model is a no-brainer from a TDD perspective. The presenter should be as easy to test. And with a passive view that one should be pretty easy to test too.