Saturday, August 16, 2008
#
Due to a change in jobs I'm moving my weblog again.
I had some problems exporting my old blogposts so my old blogposts will be staying here. You can find my new weblog over here: http://blog.mendeltsiebenga.com
Sunday, February 24, 2008
#
Jacob Proffitt has a two posts here and here on how the emphasis on TDD instead of plain unit testing is harming the adoption of unit testing.
His basic assumption (if I understood him correctly) is that people would adopt unit testing faster if unit testing proponents told them doing it without TDD is an option too.
This sounds logical if it were indeed easy to unit test without TDD. I think it's not
I found this out the hard way. Not because the testing is hard but because the code I (and some of my coworkers) used to write was highly test-resistant. I almost stopped unit testing because it took too much time to do and it took too much time to maintain the tests. The problem was that there were too much dependencies between parts of my code. Tests would be hard to write because I had to write a lot of setup code. And existing tests would fail all the time when seemingly unrelated parts of the system changed.
The solution has been well known for decades. You have to reduce coupling and increase cohesion in your code. I knew this but this is hard to maintain without immediate feedback on the quality of your code. That's where TDD comes in. By writing tests before you write code you get feedback on the testability of your code before you've written a single line of it. You're forced to think about how to call the code before it's written.
I know that I'm making an implicit assumption here too. I'm saying that testable code = high quality code. But my experience tells me this is indeed true.
If someone were to ask me how to start unit testing. I'd tell him to start using test-first on new code. Usually domain logic is easy to decouple so it's easy to test. Testing code that has been written code-first is advanced unit-testing and it's the easiest way to have people who are new to unit-testing stop doing it forever.
Sunday, February 17, 2008
#
In this previous post I mentioned that I'm not that impressed with the Template Method pattern. If you let them grow too big they be
come unreadable, untestable chunks of code that are tucked away in protected methods in subclasses that you don't call directly.
This is a simplified version of the class-diagram I showed in my last post. The main code-smell that caught my attention were the protected methods in the subclasses. The ReadHeader and ReadLine methods are only called by the ReadFile method. That's a good argument to keep them protected. But I'd like to test them separately.
Usually when you want to make code public just for testing it's a big sign the code is in the wrong class and it's refactoring time. The ReadHeader and ReadLine method shouldn't be in the TabularFileReader class but they should be in their own class hierarchy. This way they can be tested separately but it will still be encapsulated neatly because the LineReader property of the TabularFileReader is private so the calling code can't access the LineReader that's used to read the file. Another benefit is that I could get rid of a nasty code duplication between the ReadHeader and ReadLine function. The LineReader classes only know about lines and splitting them up into fields. The TabularFileReader knows about headers and fieldnames.
The code is also potentially more reusable. You can use the LineReaders separate from the TabularFileReader.
So let's recap... what have we done. The variation in the class that contained the Template Method has been refactored into a separate class hierarchy. This makes things more testable. The LineReader has become a strategy pattern. The TabularFileReader can be injected with the right strategy to make it do whatever we want.
When you want to know what's happening the code get's a lot more readable. You're calling the TablularFileReader directly so when you click 'go to definition' from your calling code you can at least see the ReadFile method.
Wednesday, November 21, 2007
#
The days of programming in just one language are long gone. To use the power of modern programming environments your code gets interlaced with SQL, XML, XPath, XQuery, Regex, HQL and more. Usually this doesn´t help make your code more readable. All the ´alien´ code lives in strings so it won´t benefit from autocompletion and syntax highlighting offered by modern ide´s and more importantly... no checks by the compiler. Any mistakes you make won't show up until you (or a customer) runs the code.
Microsoft has 'solved' this problem for Xml by making Xml part of VB.Net with Xml literals. You can now sprinkle your code with Xml. While this seems nice I think it only solves part of the problem in a bad way. Productivity won't increase by giving developers the tools to write a lot of unreadable code really fast.
For C# I'd like a more extendable solution for this problem. There's no problem with storing code in strings as long as the editor and the compiler know what to expect. The only extension to the language should be a mechanism to let programmers express what should be inside a string. That leaves the door open for your editor and compiler to call plugins to check the code without blurring the lines between languages.
Tuesday, November 27, 2007
#
Now that Visual Studio 2008 and C# 3.0 is out all the talk in the blogosphere is about what is still missing and what we want in the next version. And mixins are high on the list.
Mixins could be implemented elegantly by extending generics so you can use them for inheritance like this;
1: class Mixin<T> : T {
2: public void MixinMethod() {
3: // ...
4: }
5: }
By allowing to inherit from T you can use Mixin to extend any none sealed type like this
1: var mixinString = new Mixin<string>;
2: mixinString.MixinMethod();
It's a pity Anders Hejlsberg doesn't read my blog.
Sunday, December 02, 2007
#
And you're on the right page, the new one
My employer, Enigmatry, has been kind enough to offer me some space on a fast server to host my weblog. So here it is; Mendelevium without 30 second page-loads.
I hope more Enigmatry-bloggers will follow.
Saturday, December 15, 2007
#
1: public enum Weekday {
2: Monday,
3: Tuesday,
4: Wednesday,
5: Thursday,
6: Friday,
7: Saturday,
8: Sunday
9: };
What's wrong with this code?
This looks like C# but actually you could already do this in C in the 1970's. In those days the ability to define your own types was a novel idea but in today's object-oriented languages we expect a bit more, like extensibility or the possibility to inherit from types.
What if we want to extend our Weekday-type with a method to check for weekends? Or a 'Next' and 'Previous' method? Usually these will end up as static methods in some Utility class. Smelly! I want to be able to do this:
1: if( Weekday.Saturday.IsWeekend() ) {
2: ...
3: }
Let's try again. This time with class :-)
1: public class Weekday {
2: public static Weekday Monday = new Weekday();
3: public static Weekday Tuesday = new Weekday();
4: public static Weekday Wednesday = new Weekday();
5: public static Weekday Thursday = new Weekday();
6: public static Weekday Friday = new Weekday();
7: public static Weekday Saturday = new Weekday();
8: public static Weekday Sunday = new Weekday();
9: }
Now why exactly is this better? It looks like a lot more work.
Maybe because you can extend it like this?
1: public class Weekday {
2: public static Weekday Monday = new Weekday();
3: public static Weekday Tuesday = new Weekday();
4: public static Weekday Wednesday = new Weekday();
5: public static Weekday Thursday = new Weekday();
6: public static Weekday Friday = new Weekday();
7: public static Weekday Saturday = new Weekday();
8: public static Weekday Sunday = new Weekday();
9:
10: public bool IsWeekend() {
11: // ...
12: }
13:
14: public Weekday Next() {
15: // ...
16: }
17:
18: public Weekday Prev() {
19: // ...
20: }
21: }
Looks familiar? Take a look at the System.Drawing.Color class.
Sunday, January 13, 2008
#
One of the patterns I used to use a lot was the Template-pattern. Wikipedia has a nice article on the template pattern here if you want a quick refresher on what I'm talking about. This weekend I've been digging through some code I wrote about a year ago where I used this pattern a lot and I found it hard to read and hard to test.
The template method is a method that lives in an abstract base-class that calls a couple of abstract functions to do what it has to do. Those functions are then implemented differently in the children of the base-class to make a couple of classes that do the same thing differently. I've got a simplified example where I use it to read tabular data from comma delimited (csv), position delimited (pdv) and xml files.
The first problem was testability. The subclasses contained some private functions that I wanted to test. I could make them public to test them but then client code would be able to mess with the implementation of reading the file. The whole reason for using the template method was to abstract this away from the calling code.
The second problem was readability. Actually I found two problems here.
The first problem is that when you look at code using a CsvReader this pattern makes it harder to find out what it's doing. You expect this class to handle Csv-reading but it only handles simple subtasks, the pattern obscures the higher level logic by putting it out of sight in a base-class.
My code got even messier because I had some code I could reuse between the CsvReader and the PdvReader. These two worked with simple textfiles. But not the XmlTableReader. It made no sense to push this code up to the base-class because of the XmlTableReader. I could put it in an external class or I could add a layer in the inheritance tree above the CsvReader and PdvReader.
This looks like a neat solution. But in practice this makes the code even less readable. I've seen template method implementations with as much as 4 levels of inheritance that were completely unreadable.
So how do we make this better? I'll give you a hint. It involves dependency injection and the Strategy pattern. More on this in my next post.
Wednesday, January 23, 2008
#
A bug that dissapears when one attempts to probe or isolate it.
Found frequently in multithreaded code.