TDD and Scaffolding

· January 21, 2011

During my ventures in to new Microsoft land I’ve stumbled on the concept of scaffolding (in the form of the excellent MvcScaffolding). The concept is well known in other frameworks and one of the eye-opener features of for example Ruby on Rails.

But as I started to use scaffolding I had to stop and think for a while on other values that I have come to hold in high respect such as TDD for example. The whole concept of driving out my code guided by test has completely changed the way I code. And my code!.

I don’t feel very good about myself, nowadays, if I have to write code without tests. But this scaffolded code is not code I have written. Should I write test for it? Before the code is generated or afterwards.

Since I couldn’t find to much about it I though I jot down some thoughts on the subject. I think that it’s something that will be used more and more in the Microsoft sphere.

Definition

On Wikipedia scaffolding is defined as:

Scaffolding is a temporary structure used to support people and material in the construction or repair of buildings and other large structures.

And if you try to find a definition for programming you’ll end up with something like:

Scaffolding is a meta-programming method of building database-backend software applications. It is a technique supported by some model-view-controller frameworks, in which the programmer may write a specification that describes how the application database may be used. The compiler uses this specification to generate code that the application can use to create, read, update and delete database entries, effectively treating the template as a “scaffold” on which to build a more powerful application.

Comparing these definitions I think that a key difference between them are the “temporary” word and principle. A scaffold to raise a building is supposed to be removed as the building is finished. The scaffolded code we get, from a scaffolder, is supposed to be a guide and supposed to be built into the core of our application.

As Steven Sanderson writes:

“Scaffolding” is used by many software technologies to mean “quickly generating a basic outline of your software that you can then edit and customize”

We’re supposed to change it. It’s just some code to get up us and running. In the case of MvcScaffolding (and I think the scaffolded code of Ruby on Rails) you actually get fully working code, structured in a tried and tested way with templated views.

TDD

Test Driven Development is a way to produce great code. It makes me think about what is needed and how I am going to use it – before I write the production code. It helps me to flesh out dependencies and structure even before the code is produced. And I don’t write stuff I don’t need – YAGNI.

Oh yeah – as a funny side effect I get a test that will tell me if any of my changes down the road will break existing code (or tests.)

All this is great but here (with a scaffolder)  I get a bunch of code generated without writing a single test.

So what is it?

First – I think that code generation (as scaffolding ultimate is) is a great idea. To generate code that you don’t want to write over and over, in a well defined manner. Great idea!

But what kind of animal is the generated code. Is it my code? I haven’t written it. A tool has. I might or might now have control over what is being generated.

So it’s someone else’s code? Well not really. It’s generated for me but it’s still code. Not compiled assemblies that I include. I am supposed to change it.

And herein lies the problem (for me at least); the code is a bit tricky to classify and handle.

  • If it is my code I sure want a way to test it. Especially if I am going to do changes in it later on. Otherwise the Red light will not shine when I mess the code up later. Actually I would like to have the test code scaffolded in the same way as the production code – “tests to get me going”.
  • If it’s not my code I don’t want to see it. I don’t care how ELMAH, Unity or NHibernate are constructed internally. Or at least I don’t want to.

I suppose that the code could be a mix of those two but in reality I can’t see how to draw that line. This is either is my code (in which case I want the code to be tested) or not (in which case I hope it’s test but I really don’t care as long as it works).

What to do?

The first thing is to decide on how to treat the code; mine or not. And then face the facts from that decision.

If you treat the code as your own tests should be added. Most tools (MvcScaffolding for examples) use a templates that can be tweaked into the code you want. I would suggest that you tweak the templates to generate tests for the code that is generated.

In my current project I’ve written a tool that generate data access code (for the 1200 stored procedures we’re going to call – phew!) and here I opted to generate tests as well. The code is also supposed to change over time I wanted the team to have a way to trap any errors down the road. Also since I wrote the template with TDD that came very cheap to me.

If you treat the code as theirs, as a third party tools that you happen to generate, I would suggest to tweak the code to reflect that. You can use the DebuggerNonUserCode-attribute in .NET to do that. Maybe in conjunction with the Auto-Generated comment (<auto-generated>) like, for example in this code file.

Conclusion

OK – there you have some thoughts that have been flying around in my mind a couple of days. Would love to hear any comments on the subject. I might very well be so that I’ve missed recommendations on the subject – please correct me then. Otherwise I’ll run with this think for a while.

Twitter, Facebook