>TestRunner. It shows thousands of tests (actually only 488 ;-)), but 
>I'm only interested in the tests for my projects. 

Install the TestBrowser (from SqueakMap). You can run all test, tests for 
a category, tests of a specific test case class, a simple test method.
Much better than the simple test runner.

I also like the way VW has integrated SUnit and Smalllint into the normal 
browsers. You dont have to deal with a different tool then. 

>We should look into partitioning the tests in a more intelligent
>way (e.g. at Package-boundaries "run all tests for Package XY").

Since the TestBrowser is able to run tests for class categories and
Monticello also uses class categories for structuring packages 
both work nicely together. 

But I would prefer that the community would start to extend the meta model
with namespaces and modules.

>The Browser. The Tests-package adds a companion category to
>every class-category in the system. That adds a lot of 
>noise....

That's just a tool issue 
   
>The browser allready hides a complete second hierarchy (the
>metaclases). We switch between them using the "class" Button.
>Maybe we could hide the tests in a similar way... BrowseUnit
>allready is a step into that direction.

At least the tests should be visible if you change code ;)
  
>Another thing (not related to test that much): We really need 
>to think about is making packages more explicit: "These Classes 
>are a package and depend on those other packages". The Browser 
>should show this, and I think it should be more explicit than 
>only naming conventions... some kind of "Package-info-aware" 
>Browser is really needed.

Yes - but it requires a model in Smalltalk for Packages/Modules.

This is also required for better refactoring tools, ST refactoring
tools currently rely on a global scope.  

>I'm only interested in the tests for my projects.

That's true for a real "unit test" - it tests a unit. But there a many 
other tests one is able to build with SUnit (integration, 
performance, ...). You definitely want to run them too if they touch the 
code you've changed.

Writing a test to any class in the system (as stephane suggested) is not
a good way. You have a lot of work since you have to adapt test cases
anytime you change a single class. 
SUnit means you have to write a test for the "interface" of a unit. The 
interface is a contract and the unit test proves that the contract is 
fulfilled.

Think of the following scenario: you have a smalltalk module/package for 
doing FTP implemented in 10 classes. Your tests should prove that you 
are able to do FTP with the package by testing one or two interface classes.
If you reduce the number of helper classes, optimize the code or build
new helper classes in the package your test as well as other packages should
not be affected.

Writing good tests is much harder than writing good code!

Bye
Torsten