RSS feed
<< November 10, 2010 | Home | November 12, 2010 >>

DogmaticMVC: The MVC framework that lets you know when you suck

Yeah, I know, I know.. Does the world really need Yet Another Web Framework?

Ok, perhaps not. But I had this idea, and I felt like implementing it. The result is a web framework that takes test driven development to the extreme.

DogmaticMVC was first presented in a lighting talk at the great Java Posse Roundup conference back in March. The noticeable amount of grinning among the audience encouraged me to submit a talk about it for XP2010. And now I'm presenting it at the Smidig 2010 agile conference in Oslo next week. So I figured it was about time I blogged about it.

Let's see what development with DogmaticMVC looks like. Here's a controller responding to the /HelloWorld URL:


Pretty simple code. (Groovy code actually.) If the client is in the local machine, we output the message "Hello Localhost". Otherwise, we output "Hello world". Accessing the application from localhost should produce "Hello Localhost". Right..? Think again:


DogmaticMVC has intercepted our request, looked at the code, found that it has no tests and refused to let us run it. After all, the the code has no tests, who knows what it will do?

So we add the @TestWith annotation and point it to our test class:


Admittedly not the world's most thorough test, but hey, it executes out code right? Let's see what DogmaticMVC has to say about the matter:


66% coverage? Sure we can do better. We'll add another test that will fake a request from localhost and thus execute line 11:


So now we have 100% line coverage. Very few projects out there in the Real World have that kind of test coverage. So are you happy now, DogmaticMVC? Let's save our test and hit reload:


This is DogmaticMVC letting us know (in polite terms) that even when they cover 100% of our code, our tests really suck. They suck because they don't assert anything about our code. In fact they just execute the code blindly and do not catch that DogmaticMVC mutated our code before running it, carefully injecting bugs by switching less than with greater than etc. Really, what's the use of tests if they don't catch bugs?

We can fix that by adding proper asserts that actually detect that code is not up to spec:


Now what?


This was actually cheating since I added a bug manually just to show that DogmaticMVC will detect it and show you the failing test. Once that "bug" is "fixed", we finally get what we wanted all along: Hello world. (Or as in this case, localhost)


Not only do we have a hello world that seems to work, we have a hello world that we can actually prove will work and that we can trust will continue to work.

As a bonus for reading this long, I present to you: A new feature! Web frameworks is all about features aren't they?

Speaking of features, let us for just a minute pretend that some real customer actually wanted our HelloWorld application. In fact, they like it so much they'd buy if it it only had this extra "near" feature. Sure we can add that? It's just a couple of extra lines of code. They clutter up our class, but the customer really wants it so we end up with this:


Now what does DogmaticMVC have to say about this code?


Here DogmaticMVC no longer sees any reason to stay polite. Feature creep is turning our code into a hairball. But this time we'll pick lazy honesty over hard work Software Craftsmanship and just slap the method with a @ThisMethodSucks annotation:


Are you in Oslo next week? Come see my talk at the Smidig conference, Wednesday 17th.