Which is fine as it goes, but I’m wary of describing get/set pairs as behaviour – a bucket of data has little in the way of behaviour :-)

> Master/Detail relationships are another.
> It’s easy to test the Detail in isolation,
>but how do I test the Master without a Detail
> or Two?
>
> Just a thought. :-)

And that is where mock objects come into play. When you test A, you want to test that it acts with B and C in an expected way (e.g. when I call email on a group object, I expect it to contact the report generator and then the email server).

> So write your FileConfiguration class so it
> takes a io stream or a file name. Then you can
> test 99% of the functionality, probably the most
> important functionality, without touching the
> file system.

> As I recall one of Feather’s points was
> that if you cannot write a proper unit
> test, then maybe the design needs work.

His points where to encourage discussion, to to enforce rigid rules. In an environment where people are unsure of what and how to test, rigid adherence to a set of guidelines is useful – one people understand the concepts they understand where it is ok to ignore them. If a single classes job is to locate a named property file on the classpath, and throw a runtime exception if it doesn’t exist and it needs the use of no other (non-core) classes, I have to test it actually loading a file. I could wrap and mock the IO system I suppose, but then I’d need to test the IO wrapper – and that seems overkill for a class that loads a property file.

Accessors are typically get/set pairs, and I always test them at the same time in the same test.

Master/Detail relationships are another. It’s easy to test the Detail in isolation, but how do I test the Master without a Detail or Two?

Just a thought. :-)

> I add a functionality, I test it. Period.
>
> It doesn’t matter to me whether this
> functionality is user-facing or just an
> internal detail. If it can prevent the
> product from working the way the user
> expects it or the way it’s documented, it
> needs to have a test. Any test.

But my point was that by not having a fine-grained unit test you loose much of the benifits of testing at this level (and therefore many of the benifits of TDD), namely:

• promoting loosly coupled, highly cohesive code
• small units of code with good test coverage promoting frequent checkins
• small units of code with good test coverage promote refactoring at a small level
• Testing at a smaller scope makes it easy to cover all execution paths
• Large scale tests seem to promote state-based testing rather than testing of the design – less mocking, more asking – which isn’t going to help a tell don’t ask OO design.

Without some mental note to “only test one class at a time” you’ll quickly find any team writing tests for a larger and larger scope.

Michael Wrote:

> By all means, write the test. The point is
> really to think about what could be tested
> independently of the file system. Defining
> ‘unit tests’ narrowly, like I do with teams,
> is really an invitation to think about that
> issue.

Agreed – it comes back to rules being there for the guidance of the wise and the obidience of fools I suppose.

Here is a follow-up challenge: among all the TestNG tests that you’ll find there, count how many are unit tests and how many are not.

I wrote most of these tests myself and to be honest, I have no idea what the answer to this question is, and actually, I believe that it doesn’t matter at all.

I add a functionality, I test it. Period.

It doesn’t matter to me whether this functionality is user-facing or just an internal detail. If it can prevent the product from working the way the user expects it or the way it’s documented, it needs to have a test. Any test.