German got my point.
The idea is to have simple unit tests visible to push us to produce 
more tests.

On 19 déc. 03, at 19:03, German Morales wrote:

> 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
>
>