Redefining the Unit

In my post on dotNetRocks I said

A chance to redefine the ‘Unit’ I’ve always thought that Unit Tests were a bit of a misleading name. A unit test generally corresponds to a method. And in that unit test there are multiple test cases. So really the test case should be considered the ‘Unit’. Don’t get me wrong I think that knowing what tests a method is very important. But by redefining to the test case, we can then link it in to bug tracking better and say, “this particular test tests this bug.”

In hindsight, I think I should have left this out of the email, it’s cool but it isn’t a core idea. I also don’t think I explained (or could have explained in the time frame) enough.

When we refer to the unit we are talking about a single build block, as google defines it:

a single undivided whole

The keyword is undivided. So I see it as the same as atomic. It should test a single thing which is a test case. Many of these units could be put together to give a complete test for a method.

I think this problem occurs because we are stuck in a programming language instead of a testing language. We have a class and we have methods, so our class is our fixture and each method is a Unit Test. And that’s all the grouping we do.

A final thought, a testing language shouldn’t have the idea of writing classes and methods (obviously it must interact with them from the programming language).

Hope this clarifies what I may have confused some people with, there is another idea which I don’t think I clarified enough and I hope to post about that soon.

Concept: T#

I while back I was listening to James Whittaker on DotNetRocks! (strongly recommend all developers listen to it.) Anyway it got me thinking about exactly where we are with testing. The two biggest things I thought of was…

• We don’t teach testing well. James Wittaker pointed this out and it’s completely true. When I was at uni the closest thing to being tought testing was being told to write unit tests for an assignment (yes 1 assignment and we had to figure it out ourselves)
• We reach the potiential of the unit testing frameworks (NUnit, JUnit) a long time ago. Everything since has been minor and not worth talking about. I think that the NUnit guys have realised this but it isn’t helping their attempts to improve. I read that they’re big update they’re working on is changing
  Assert.AreEqual(expected, actual); to
  actual.Should.Equal(expected); via extension methods.
  This reads a bit nicer but it is really the same thing and doesn’t change or improve how we test.

So what’s next then? Well I think for this we have to look at another hot topic – Domain Specific Languages (DSL). I don’t want to go into what a DSL is, you can find plenty of information online, but I believe the future of testing is having a Domain Specific Langauge for Testing.

A language specifically made for testing, to me this is what .NET was made for! Just thinking about the idea questions practices we’ve always used

• Why do we write tests in the same language as our code?
• Should tests be written in a functional or object-orientated language?
• Should the tests be static or dynamic languages?

This really the basis of my idea for T#. Look out for more posts to come!