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.

Alt.Net Registration...

Is now open -- register here, see who's coming here

The conference is limited to 100 people, so register quickly.

Hope to see you there!

Last day of Agile 2007

Its been a fun Agile conference this year. I met a lot of people and had plenty of interesting conversations.

I'd like to thank everyone who was at our tutorial on pair programming. You were all great and I hope you had as much fun as I did!

Taylor the Sailor found me after the session and asked the question you were all dying to know... "Do you really know what an NPC is?" Of course I do!

For all of you wanting to know why we were talking about D&D, I'd usually say you'll have to come to our next session. However, I don't think it would be as fun a metaphor without Oksana saying, "I have no idea what she is talking about, but I know it has something to do with video games." It is probably the last (and first) time I use it as an example activity that's best to do with someone else.

Today, Ken and Ilio's presented their experience report on Ript. They did a really great job. It was fun to be in the audience of another team members' session!

I'm really glad the whole team was at the conference. I'm really lucky to work with people I admire and enjoy so much!

With all this great team spirit its hard for something to compare. However, on the first night, they had a balloon guy at the ice breaker and he made me a bicycle! He didn't even call me a hyena for asking :P