Mantis - Squeak
Viewing Issue Advanced Details
5639 SUnit feature always 12-14-06 05:38 10-03-09 19:34
Keith_Hodges  
andreas  
normal  
assigned 3.9  
fixed  
none    
none 3.11  
0005639: proposed improvements to SUnit specification of suites
SUnit defines test suites by the method selector prefix 'test'. This proposed improvement enables a TestCase to publish a number of test suites rather than the one standard one. Test suites could be defined by a broader criteria.
 SUnit-kph.38.mcz [^] (26,441 bytes) 12-14-06 07:15
 SUnitGUI-kph.13.mcz [^] (13,001 bytes) 12-14-06 07:15

Notes
(0008712)
renggli   
12-14-06 10:16   
- Why new naming conventions that clash when ortogonal suites need to be defined?

- Why a static declaration of #publishedSuites when we are in a dynamic environment? What do I do if I want to change an external test?

Btw, Pragmas would solve all these problems nicely.
(0008722)
Keith_Hodges   
12-18-06 10:24   
1. have added support for orthogonal concepts via #publishedFilters

2. there is nothing to stop #publishedSuites or Filters being generated dynamically.

see TestCaseVersioning-publishedFilters which publishes a filter according to the current platform.

I dont see what pragmas would solve exactly. How backward compatible are they? And of course if something is not documented (or UIed) it may as well not exist. Googling squeak pragmas, unfortunately brings up nothing of interest.
(0008723)
renggli   
12-18-06 20:00   
> 1. have added support for orthogonal concepts
> via #publishedFilters

That doesn't solve the problem.

> 2. there is nothing to stop #publishedSuites or Filters
> being generated dynamically. see TestCaseVersioning-
> publishedFilters which publishes a filter according to
> the current platform.

I don't request that.

What I want is to tag an external package without overriding or otherwise modifying its code. As an example, tagging a test as slow / not compatible with a platform / ... might not be true in my context, which is different from the one the developers of the package / other members of the project team / ... are in.

> I dont see what pragmas would solve exactly. How backward
> compatible are they? And of course if something is not
> documented (or UIed) it may as well not exist. Googling squeak
> pragmas, unfortunately brings up nothing of interest.

Type 'smalltalk pragma' and choose the first hit: http://www.cincomsmalltalk.com/userblogs/vbykov/blogView?entry=3266621229. [^] There is class documentation (search for Pragma in a 3.9 image) and a big set of unit tests (search for PragmaTest). There was a lot of discussion about pragmas in the mailing list, the archives know everything.

I can repeat the main idea: To avoid useless naming conventions that need to be hacked sooner or later anyway and you tag your messages with a pragma (or method annotations, to say it different). In your case this would be probably <suite> and it would tell the test runner that it can safely call this method to get a test-suite.
(0008735)
Keith_Hodges   
12-21-06 09:18   
The ability to categorise, and subtract/select from a category with a filter is pretty useful and the UI has been updated to make all the new features fully accessible. The new features are useful for users of the test framework as it is.

These new features should be just as useful for any tests or suites defined using a pragma (method annotating approach). [Ill have a go after SSpec integration]

Note that suites and filters defined using 'include#ToDo' pick up on methods flagged using self flag: #ToDo. or even methods containing simply '#ToDo'. Ok this is not pragmas, but it is a backwardly compatible equivalent.

Defining #publishedSuites in a method keeps everything visible and simple. There is no background magic. It also provides more control for customizers of TestCase to programmatically return different suites/filters in different situations. The <suite> pragma idea may not provide the desired functionality, for example it is not (as I understand it) possible for a subclass to clearly control whether an inherited suite is in or out.

I have also extended TestRunner to have #baseClasses, rather than just #baseClass, this was primarily for SSpec support since SSpec classes do not inherit from TestCase. Therefore a logical step will be to define a third baseClass for test cases defined in pragmas.
(0012910)
Keith_Hodges   
01-10-09 00:15   
Currently this code is available via Universes and Sake/Pacakges 'SUnit-improved'
(0012911)
Keith_Hodges   
01-10-09 00:16   
Is part of the release-candidate