About test presence

ducasse ducasse at iam.unibe.ch
Fri Dec 19 12:54:06 UTC 2003


On 19 déc. 03, at 11:12, Peter van Rooijen wrote:

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

For me I want to use SUnit because this is somehow standard and we do 
not have tests
within class.
>
>> 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?

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




More information about the Squeak-dev mailing list