About a month ago, I started to explore some of the options available to us CLR coders if we want to use  BDD/specification style testing from a dynamic environment. Sadly, the executive summary is that currently, there aren't any working solutions available. Or - happily, I was thrilled to discover that there are many efforts underway that will provide us with such tools, and they will be complete pretty soon!

First off, I looked at the C# non dynamic BDD oriented tools: Nspecify and nspec. NSpecify is nice. I didn't like the external (extra compilation step) approach taken by nspec. Anyhow, what I really want is some dynamism!

So, then comes specter to the rescue. Specter is written in boo (a pythonesque like language) that offers many dynamic features beyond what C# 3.0 has (even some that ruby doesn't have, but then there are many that ruby has and boo has not), for example ducktyping. Specter is a specification style framework that lets you create NUnit test assemblies using a very concise and nice syntax. So, all was great until I hit some of the limitations: Boo does not support generics. So, I cannot test methods that return a generic list of something.

As soon as boo becomes ready for primetime, specter is the best choice I have seen so far because of it's nice environment where there is ample support (sharpdevelop 2 is really not bad).

Lastly, I thought - why not use rspec to test CLR code? I figured, I want to try that ruby CLR compiler they made in australia. Well, I downloaded it and took it for a spin, and checked the docs. It looks promising but it turns out that it does not create standard CLR assemblies yet, and it cannot access CLR assemblies: Whatever you create with the compiler lives it's own independent life.

Well, another thing that looks really promising, but alas, at this point in time there is no real solution. Boo is making progress on the generics side, and I assume that the garden point ruby compiler for the CLR will advance as well.

The future looks bright, we'll just have to calm down and relax a little longer.

The topic of the architect role in software development surfaced here at oopsla as well, during lunch. In common with many fuzzy concepts, there is an inconvenient confusion surrounding what an architect is, which overloads the term and makes it less useful. One issue we all agreed on was that it is bad for architects to stop writing code, architects that do not program any more get disconnected from the operative aspects of development. This phenomenon brings problems.

Without motivating that further, lets have a look around and see if we can't see a pattern in where we see that phenomena, or not: If this type of non-coding architect is  good, we should be able to find architects like that amongst the most productive, effective and best development teams. There should be people that we look up to in our field that are like this.

I don't think there are too many like that.

After lunch when we've talked about this, we listened to Joshua Bloch (from java fame, currently chief java tech architect at google) who said this at the beginning of his talk:

"If you code, which I assume that all of you here do..."

Immediately, I thought of the conversation we had during lunch. I do think that this is widely recognized as a problem in our field, and that it in turn is a symptom of a couple of problems, a major of which is the career path problem - where is an experienced developer to go? A company wants to keep the competence and knowledge that the individual has gained, yet he is not interested in becoming a "leader". One option is to give the developer a new title - "architect" - and then he can influence several teams. Up to this point, we are not actually doing so bad - this may all be fine.

But then something happens, at some point it becomes ok to stop coding, the motivation runs out, or the organization pushes so many papertasks on the person that he loses touch with how to program software.

We have to start thinking about issues like this, and more to the point start acting on those thoughts. We need competent architects (as well as tech leads and devs) to succeed! Just as we push and put high requirements on ourselves (I am speaking as a programmer), we must do the same for other roles working on or with the team. Remember, you have to start change wherever you are, talk about the problems in a constructive way - what do we loose when people who cant remember how to create software actually dictates the design and creation of it?

Once you are or have a great architect on your team, be happy for they are fairly uncommon.

I was just informed that Bertrand Meyer is also coming to Öredev 2006! This is great news, I have never heard him speak - another good reason to come to Øredev in November. Martin Fowler, Jim Coplien, and just a host of other great people are coming. Speaker overview.

TDD offers benefits in terms of both project/work dynamics and software quality. Some benefits are obvious (feedback from tests) but most are not (small steps lead to a higher frequency feedback loop and more control). One view of this is that some benefits come as a by-product.

TDD / BDD (I'm going to use BDD from now on, substitute as you see fit) gives testability as by-product. This is basically the view expressed by Jungmayr.

The simplicity of the BDD method makes it general, flexible and adaptive. The flipside to that flexibility is that there is ample room for misunderstanding.

Does BDD prescribe testability? No. Indirectly, your designs *should* become testable if developed using BDD. However, there is no "step four" (after RGR) that says "review code for testability or maintenance issues and fix them". It is often not part of refactoring since testability affects design and "unit" (usually class, YMMV) functionality may indeed be altered.

Instead, BDD infuses many testability, maintainability and other factors of high quality software, through its focus on testing one small thing at a time, "small-scale tests", and eliminating duplication. In order to test just that one thing you must figure out a way to replace what it interacts with. You must be able to manipulate the link between them; you must make the dependency "loose". The consequence of this is that all classes will depend on each other loosely. They will not have hardwired dependencies.

Hardwired dependencies are when class A is coded to always use class B. This may be since it A itself creates B or uses static methods of B.

This makes the code less testable since there is no direct way to test a part of the system, by manipulating the dependencies. We have to use other means, via a more complex test harness, and/or tools.

So testability comes as an indirect result. But can we say it is a byproduct? Is it true that this is not a systematic way to get testability in our code?

Even though most misunderstanding is a product of ignorance, would there be a way to make TDD more explicit (in how benefits are addressed) by design? I am unsure, I agree with the idea that understanding in the form of realization is often impossible to transfer. It has to be experienced to materialise. Often, the best that can be done is offer guidance and direction, a map to where the realization of knowledge lies. The question then becomes if the benefits require such realization or can be reduced to following a systematic approach.

Short: An example of learning as the result of rotating; using techniques learnt from working with testability in new (TDD/BDD) development.

On the microlevel, we learn from inspecting the code we are creating. On the macro- or project level, we learn skills in one type of project that we can use in a project of another type. Essentially, the difference between legacy and greenfield. Working with many legacy projects, we can see the results of our mistakes, and we can see how we can work around them.

This turbocharges our learning, since the issues are magnified.

I've experienced a useful example are TDD/BDD techniques. BDD gives us insight into our software designs, it illuminates values of our designs that are very hard to find otherwise.

I think it was Pete McBreen (or maybe Alistair Cockburn) that drew the parallell to how many martial arts methods are taught, usually in several levels - the masters have apprentices that teach the novices. The novices magnify the mistakes of the apprentices. The mistakes become easy to see, the feedback is clear.

 We get this magnification when we look at code a little further on the timeline, when it has been in production for a while. The problems caused by any design decisions we made when developing make it easier to see how design affects maintainability.

For most of 2006 I have been working with projects where the challenge was in making the code testable and then adding tests. I have discovered that when I return to new development projects, many of the techniques I learned while working with existing code have helped my understanding of the BDD issues.

So for this example, if you haven't done any "refactoring old code" project, and haven't read the WELC book - I recommend doing it. There are many things you will learn from it, testability techniques not the least.

Rotation is good, both in the small and in the large.