It's Just Syntax

I have been a developer for more than 15 years. I have written a lot of code in that time and have seen the profession of software development grow and mature in that time. Many things have evolved and the old way of doing things drops away as the newer practices come in to replace them.

I am not new to agile but I am also not a guru. I learn something new everyday and one of the more interesting things I have recently experienced is TDD and mocking in a new language. Not a new one on the scene but a new one to me - C#.

Now for many this seems kinda strange since Visual Studio, .Net and C# have been in the mainstream for a long time. I haven't used Microsoft development tools since Visual Studio 6 and even then it was for VB. I have been in the Java world since 1998 or so and it came to be my dominant language over time. I have played with Ruby, Groovy and a bit of Erlang but primarily I have a Java geek for a while.

That being the case, all of my real world agile experience has been learned and internalized using Java and JEE.

So...

I get a client who needs something done fast. The caveat is that I know this client from way back and I know that it has to be Windows-based, it needs to be one click install and feel native. Naturally there are ways to do this with Java, and Ruby an the rest but, really, on a Windows box for a console type app VS with a standard msi install is just a natural fit. This is what leads me to think "Well, I guess I will take this opportunity to see what it looks like in MS these days and since I have done VB but not C#, why not?"

A natural thought and so I take the plunge. This is where it gets interesting because since the last time I worked with MS and VB I have become an agile developer who needs my TDD and Mocks to know I am doing code right an doing just what is required an no more than is required to built the product correctly with high quality. This is the natural way for me to work and so I look into tools for this.

I came across NUnit and I was pretty happy since it crrelates really well with my Junit experience. Then I find RhinoMocks and Moq and I was pretty happy with those too. I turn my sights on a coverage tool and I hit a wall.

Visual Studio Team has the coverage but I am not going to shell out that kinda money for a "team" product when all I need is the coverage piece, Professional Edition is fine. There must be something else. The product that gets all the mentions is Ncover with looks really nice. The problem is that it went commercial and is a bit pricy for a single tool, especially after I spent the money on VS Professional.

Finally I come across the cost effective answer - TestDriven.Net. It bundles Nunit (several versions) and Ncover in a single tool that integrates right into VS. Sweet. The whole setup meets my desires and I start working.

I am sure I am not the first one to experience culture shock taking my customary agile practices from one language to another but I will say that I was mighty surprised at the roadblocks I came up against. I am not going to run down a big list of the problems because it could be construed as a critique or rant on MS and Visual Studio and that is not my intent. In reality I am impressed with some language features.

My difficulties revolved around the fact that much of what I considered to typical TDD methods are really very Java-centric TDD. An example is the abilty to inline override a protected method of a class online in a test to provide stub or fake behaviour of the class you are testing. This is a simple an favorite technique to override simple things light property configuration.

Another thing is that accessor methods in .Net don't work the same way as Java's do. And why should they? Stupid assumption on my part. Adding to this that packages don't equal namespaces and where your tests are in the same namespaces as the class you are testing you still don't have access to protected methods because friendly doesn't work the same either. Again, why should it and dumb assumption. What this leads me to is a lot of public methods where I don't want them public.

Now before I get a deluge of "You missed the obvious!" I will state for the record that I probably have missed the obvious. I realize that. But that isn't the point of this post.

The point is that I am learning that much of you TDD skills are very dependent on your language and development environment an it helps to be aware of this. I am coming up with new techniques, possibly better techniques, for doing testing in a different world. And I believe this makes me a better developer for it. You have to adapt to change and changing the dev environment and language is a fundamental way to teach you to do that.

I am still good at TDD and I am still good at agile. I have to learn to adapt and develop in ways that I wouldn't have had I stuck with my comfort zone. And the next time I switch languages I will be ready and I think I will cope better. Best of all I will know that TDD and agile is possible regardless and, as every developer who has been around a while will tell you, it's just syntax.

In the long run most concepts in programming aren't that different. It is really about knowing the concepts and learning where to put your fingers on the keyboard.

-- JMH