Comments on what i still don't know: Test Code Is Just Code

I just had a great Monday morning when I saw this ...

2009-04-27T04:20:00.000+01:00

I just had a great Monday morning when I saw this post... I remind people all the time how important tests are.. but sometimes I feel like some devs don't value tests as much as what they call "the production code".
One big problem is "design". We should design the tests as well... Refactor.. create abstractions, remove duplications whenever possible without removing the ability to read the test.
Perfect, congratulations Ian,
very good post..
I'll refer to it whenever I have one of these discussions when people argue that "tests will not go to production..."

I think the big objection I hear about writing tes...

2009-04-23T10:23:00.000+01:00

I think the big objection I hear about writing tests - particularly unit tests - is that as the code evolves then you have to re-write all the tests and so you are wasting time with all that test maintenance.

I say that if you need to change tests all the time then you probably aren't doing very good OO development. Classes that are well encapsulated with good interfaces that consume other interfaces via IoC will be flexible and composable and more than likely they will also be easily testable.

I also wrote this in a similar vein:

http://nomorehacks.wordpress.com/2008/11/05/when-is-a-unit-test-not-a-unit-test/

Very good post. When I first encountered TDD, this...

2009-04-23T09:58:00.000+01:00

Very good post. When I first encountered TDD, this was an epiphany for me. I began writing lots of tests, which helped tremendously - but I did not give as much thought to the organization of my tests suite as I did to the project itself, and over time the tests themselves started to become painful to work with, for pretty much the reasons you listed. The morale of the story for me is the same as for "regular" code: write it as if it's going to grow, and as if you will have to look at it later when you have forgotten everything about the project...

Really refreshing to read this. I agree with every...

2009-04-22T20:59:00.000+01:00

Really refreshing to read this. I agree with everything said in this post.Test Code should be treated as production code.

IMHO this is a slippery slope because

* When a development team is behind on schedule, I have seen devs start cutting corners in test code. That is when the Copy Paste syndrome which you highlight often comes into play. When I look at something like that these days, I thank my stars that atleast there is a test.

* If TDD'ing an area of code has become overly complex because of bad usage of mocks etc.. this often does not figure out in the Technical Debt list of a team.

* Test code refactoring also never gets considered when devs think of estimating a story, especially when dev team is too focused on getting the story done

In an ideal world, constant refactoring of test code along with production code should happen as a part of each story, and as we know the system better each day

Excellent advice. I've already referred people to ...

2009-04-22T20:14:00.000+01:00

Excellent advice. I've already referred people to it.

Because code "talks to the developer", and test code is code, then the intention of the test should be clear.

If we're using tests as executable specifications of system behaviour, then we should be very deliberate about how those specifications are expressed.

Names are very important, as is the abstraction of infrastructure (like SQL, HTML, even web testing tool API) as you describe.

The advice here will help high-performance teams have purposeful, easy-to-change tests that allow rapid turnaround of business requirements.