About test presence

German Morales germanmorales at delta-sys.com
Fri Dec 19 18:03:06 UTC 2003


Hi,

I think two of your points are very similar, so I answer to them together.

> First, it leads to test code that is too tightly coupled to production
> code. The test code is structured according to the design of the
> production code, and this makes refactoring difficult. The tests should
> reflect the requirements for the software rather than it's
> implementation. For effective refactoring  it's best to have stable
> tests that allow the production code to be changed independently.

> Finally, tight coupling between tests and production code makes tests
> less effective as documentation. If you structure the test suite around
> concepts of related to the requirements of the software, it becomes
> much easier to understand the software by reading the tests. Expressing
> the requirements and implementation with separate models give you two
> views of the problem and solution, as it were. By tightly coupling the
> tests with the production code, you only provide one expression of the
> information that needs to be conveyed.


I think there are different levels of tests.

As you say, there are tests that test "the requirements for the software".
These tests, if I understand what you mean, see the application as a
whole, as the user will see it.

The problem I see with this high level tests is that you need a fully
working (part of the) application to have those tests passing.

While making those tests work, you incrementally build smaller parts that
you later join. Being test infected, you want to be sure that those
smaller parts work perfectly, so you end up writing tests that are closer
to the implementation.

I don't think this low level tests are something bad by themselves. The
problem would be having only this kind of tests and none of the other
group.

So I think is a matter of education, of learning how to write better tests
(and i'm not saying that I have any truth on what's better).

And talking about testing education, I think that's what was Stef was
pointing to.

Your comments are ok for a discussion about "how to write better tests".
But I suppose Stef is looking for weapons to win a more simple discussion:
"to test or not to test".

That's where BrowseUnit fits. It destroys the excuses of people trying to
avoid getting test infected.


Have a nice day (and 2004, why not?),

German Morales




More information about the Squeak-dev mailing list