Skulls are fun!

Who would have thought Halo could be improved with some skulls? It really makes the campaign rock :)

I can't play without the grunt birthday blast. How else can I be sure I'm getting head shots?

Did you know bungie keeps a detailed record of all your games? If achievements weren't enough to keep me going...

Good practices are beyond testing

Before using TDD, I was a big fan of separation of concerns, single responsibility and inversion of control. These things have proven over and over again to be priceless.

When I started using TDD I loved is how it enforced these principles. I couldn't maintain or write tests without them. Testing even forced the need for dependency injection and inversion of control containers.

The tests started to validate and enforce important behaviors. Behaviors some people don't appreciate. Sometimes these had been a hard sell.

TDD became an easy justification for best practices. How awesome!

Enter mocking libraries that don't require DI. You can mock everything from constructors to static methods. Mocking methods on the CUT is as easy as creating a new class for that responsibility.

With this, its easier to make a large class and use static utils and real constructors. Now you can test without adding those pesky things that add to the confusion of object oriented code... you know stuff like interfaces, polymorphism, encapsulation...

If we don't need DI or interfaces for testing, then why do we need them? If testing can happen without it, then that behavior isn't driven, right? Why can't I make a big class if its testable?

But these design principles have been around for a long time and for good reason. DI, single responsibility and separation of concerns were not born from testing.

If only this really existed

If they would feature this service at software conferences, that would be most excellent too!

Does Intuitive == Maintainable?

What makes code maintainable? What does it mean to be readable? Why does it matter?

My coding standards and styles change constantly.

I have yet to return to a project after a hiatus and understand it without some investigation -- no matter how intuitive it originally seemed.

If this is so, how can something be maintainable? If a project can be written in a few weeks and then not touched for several months, is there any chance you'd automatically understand or agree with the design?

There are very few solutions that cannot be figured out. Sometimes it takes minutes. Other times a bit longer. A lot of times it involves grimacing, cursing and questioning the sanity of the original developer(s).

But no matter how "awful" a solution may be, at one point it made sense to someone, so with some detective work it can be understood.

Something common of software that is easier to maintain is single responsibility and separation of concerns. These principles are not subjective. They don't change with time, mood or business domain.

If a project follows these principles understanding the entire system isn't necessary, just the part that needs to change. It may take some time to find it, but once found, the solution is simple.

Countdown to Halo 3...

Its almost here... the reviews are in and, well, outstanding.

Eternal Sonata is keeping me busy in the mean time (I highly recommend it for all you JRPG fans!)

So many games (Halo, Rock Band, Guitar Hero 3, Mass Effect, Beautiful Katamari...), so little time... I don't think I'll be blogging much this fall :P

And I still didn't beat Bioshock on hard...

Too many mocks?

As I write tests, I use mocks to push off behavior that is difficult to test. This pattern helps me focus on the class under test and drives my design.

At what point can you push too far?

With TDD, its all about your tests, so anything that helps you write a test is the right thing to do. I am confident the tests drive a good design.

However, sometimes there are border cases. You may wonder if another class is excessive.

In this case ask a simple question: is this behavior the single responsibility of this class?

Usually the answer is no. The behavior I'm testing is combination of responsibilities and so, yeah, a mock is a good choice.