On Dec 18, 2003, at 1:43 AM, Frank Shearar wrote:

>>> I would like to add in the image the corresponding tests that marcus
>>> collected and produce a removal script (which is trivial).
>>> Before doing that I would like to know your point of view.
>>
>> Put my vote for BrowseUnit, it's just perfect for the task.
>> And I looove using it.
>
> Yep yep! First you get test infected and then you get BrowseUnit 
> infected.

Hi folks,

I'm afraid I must vehemently disagree with this position. I think it's 
a bad idea to couple the tests tightly to the code being tested. The 
problem with BrowseUnit is that it insists on a conventional 
relationship between the two. A ratio of one test case to one 
production class is fine in theory, but in practice there are several 
problems:

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.

Second, it can lead to performance problems. If tests are structured 
just like the production code and any of the setUp or tearDown involves 
expensive resources, it can take quite a while to run the test suite. 
The longer the tests take to run, the less frequently they tend to *be* 
run, and thus provide less benefit to the development process. By 
structuring tests according to the fixtures they require, it's possible 
to significantly improve performance, and make the tests more useful.

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.

In short, there are many ways to structure a test suite, and different 
structures provide different advantages and disadvantages. By enforcing 
strict conventions for test cases, BrowseUnit, forces developers to 
couple test and production code too tightly, reducing the usefulness of 
the tests. I think it would be a real shame if this convention were 
adopted and enforced by the Squeak community.

Colin

PS. I'm partial Kazuki Minamitani's TestBrowser, although it hasn't 
worked well in recent versions of Squeak. I'd love to see this kind of 
tool further developed.