Continuous State Check

Another post about my ideas on T# expressed on DotNetRocks.

One line which I think was too specific for that discussion was

Make it easier to express testing ideas – one small idea I had with this is during a test there is often a state which you want to always check. T# could provide a mechanism for checking it after every line so you don’t have to have every second line as an assert.

I think this was way too much of a potential implementation idea and took away from the focus of why T# is necessary. And the problem with an implementation detail is they are hard to properly explain in 2 sentences.

The idea is best explained with a form. There are some statements that always going to be true for this form. For example, The save button’s enabled only when the business object is dirty. Now let’s say we write a test which does a heap of operations on the form. Wouldn’t it be useful if after every line of our test it checked that the continuous state is correct?

That’s pretty much the idea. To put it in a real example, imagine you’re on holidays camping (Yes I’m taking the explain as a tour idea from James Whittaker, what can I say it’s a good technique). While there there you are going to face several scenarios. But though them there are always some checks you want to make, “Do I have enough water?”, “Do we need to start setting up camp for the night?”, “Is this a suitable place to camp?”. These checks are the tests the touring is just potential scenarios which could cause our tests to fail.

So by having our definition of continuous state separated from our tour of the code, we are separating what are our test definition and our exploration of the code to find any scenarios where the tests fail.

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.

Thoughts on T# on DotNetRocks

As I posted earlier I sent the DotNetRocks guys an email about T#.

I though I’d post a few thoughts on it.

First I really should have thought ahead a bit more and not have written any code, I would have said it leaving out all punctuation – “Assert are equal object1, object2 as opposed to object1 should be equal to object2.” But in written form it doesn’t make the point as strongly.

I would like to point out that I think Nunit is great, and yes, this new way reads nicer, but it just doesn’t change how we test. I think I stated it well in my original post here.

I also think I went into too much detail for the podcast, I think I simplified some of the ideas too much and it probably left people think “huh?” I think the last paragraph was unnecessary. I’ll post something in the future which hopefully explains this idea a bit more.

I also agree with Richard that something like this is probably already in the works. I also just realised that some people reading my blog may think I’m implementing the idea. I’m not and I’ve never planned to, my blog posts on T# are completely theoretical, and allows me to express some ideas on how this could be implemented and why it should be implemented.

T# on DotNetRocks

A quick mention of my idea (and me!) was mention on dotNetRocks today. It’s in the first 10 minutes – http://www.dotnetrocks.com/default.aspx?showNum=436

A look at Domain Specific Languages

Just thought I would talk about one of the points I made about T#: “Should tests be written in a functional or object-orientated language?”

I doubt T# would be a functional or object-orientated language. It may have elements of both but it should be viewed as a Testing language and everything about it should be to make testing easier.

A lot of people say DSLs are bad, and there definitely is a dark side to them. But there are several DSLs which are commonly used. They are very different from General Purpose Languages and by thinking about them we may see just how different a testing language could be.

SQL

The domain is obviously Querying. It’s very simple and very effective. It is interesting to note that you could write your entire business logic in SQL, but obviously not a good idea. This gives us an interesting point about a DSL – they may be used for something outside of it’s domain but achieving it is probably simpler in another, more appropriate language. Because of this we should not try to add conditions outside of our domain.

LINQ

Like SQL, LINQ’s domain is Querying. It was designed to make Querying more declarative inside your code. It is functional even though it is used in an object orientated language.

From here a start getting into an area of grayness, and as I go the question of, “Is that a programming languages?” gets asked more and more.

XAML

Is XAML a programming language? I would argue yes. It is a Presentation Markup programming language (So it’s domain is Presentation Markup). With WinForms our GUIs were C# or VB.NET with a nice editor. Now a lot of that is put into XAML. It also has a way of interacting and calling our code behind. We may not see this as a programming language because it’s not procedural, but that’s the point – the language was chosen to make creating something in it’s domain easier. We could use a general purpose language like C# instead, but XAML makes the job easier.

ASP.NET

Similar to XAML but a little bit more gray.

HTML

I still can’t bring myself to say that HTML is a programming language. A week ago I could say with certainty it definitely wasn’t, last couple of days I’ve been questioning it. For starters how is it really different from XAML? I mean it’s more static, but you can still call javascript. To put it simply HTML provides commands which the computer interprets and creates an output of. My main reason for not calling it a programming language is if you call HTML a programming language does that mean that word is a programming language?

Word

“I program in Word!” It just sounds wrong, makes you feel dirty and seems to insult you as a developer doesn’t it? But could you say that it is a domain specific language where again its domain is Prestation Markup. Wikipedia defines a programming language as “a machine-readable artificial language designed to express computations that can be performed by a machine.” So a language that tells the computer what to do; does that include how to display stuff? It’s a slippery slope.
I wonder if the reason is others and myself refuse this concept is just our egos. We take pride in what we do and that it’s something that not anyone can pickup and start using. We are afraid that by saying that word is a programming language we are saying, “You know what writing a complex business application is like? Writing a word document. It’s exactly like writing a word document.” Which is ridiculous, it’s like by admitting that plugging in a light bulb is dealing with electricity a electrician is saying that all electronics is as easy as that.

I hope this gives you some idea how different a testing language could be from a general purpose language. I would like to make it clear that I have stopped short of calling HTML and Word programming languages, but I hope I’ve opened the topic up for discussion.

I’m very interested in what other people think. Do you think HTML is a programming language? Could you ever accept Word as a programming language?

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!