> 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

Stephane,

Earlier you asked for the simplest possible solution. I said something about
that (tests in the regular classes), but you seem to have ignored it. Is
this because you think no special test classes is *not* actually the
simplest possible solution, or is it for some other reason?

> After if people wants more we can discuss. For now I would like to have
> tests testing the current
> image much present

If I understand your words correctly, you want the tests for the code in the
image to be more easily accessible. Is this so that it is easier to run
tests for whatever you have in your image, to see if a change you made broke
anything? Plus to have examples of usage readily available? Plus it makes
the tests more visible, so they are more likely to be debugged and new ones
written?

If you have those kinds of motivations, I agree with you totally. Test code
in the classes under test gives you those advantages and more.

Regards,

Peter

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