Hi colin

for me I just would like to have some consistency:
	knowing how to name the testCase according to the class name
	for Integer having IntegerTest
	and for the category the same as the class but with tests

After if people wants more we can discuss. For now I would like to have 
tests testing the current
image much present and regular because regularity is related to beauty 
when this is well defined.

Stef
	

On 18 déc. 03, at 23:54, Colin Putney wrote:

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