0005639: proposed improvements to SUnit specification of suites

Notes
(0008712 - 275 - 299 - 299 - 299 - 299 - 299) 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 - 491 - 527 - 527 - 527 - 527 - 527) 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 - 1571 - 1733 - 1929 - 1929 - 1929 - 1929) 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 - 1336 - 1390 - 1390 - 1390 - 1390 - 1390) 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 - 81 - 81 - 81 - 81 - 81 - 81) Keith_Hodges 01-10-09 00:15	Currently this code is available via Universes and Sake/Pacakges 'SUnit-improved'

(0012911 - 32 - 32 - 32 - 32 - 32 - 32) Keith_Hodges 01-10-09 00:16	Is part of the release-candidate

Issue History
Date Modified	Username	Field	Change
12-14-06 05:38	Keith_Hodges	New Issue
12-14-06 07:15	Keith_Hodges	File Added: SUnit-kph.38.mcz
12-14-06 07:15	Keith_Hodges	File Added: SUnitGUI-kph.13.mcz
12-14-06 07:17	Keith_Hodges	Note Added: 0008711
12-14-06 07:17	Keith_Hodges	Note Edited: 0008711
12-14-06 07:29	Keith_Hodges	Note Edited: 0008711
12-14-06 10:16	renggli	Note Added: 0008712
12-14-06 10:25	renggli	Issue Monitored: renggli
12-18-06 10:13	Keith_Hodges	Note Edited: 0008711
12-18-06 10:14	Keith_Hodges	Note Edited: 0008711
12-18-06 10:24	Keith_Hodges	Note Added: 0008722
12-18-06 10:26	Keith_Hodges	Note Edited: 0008711
12-18-06 10:38	Keith_Hodges	Note Edited: 0008711
12-18-06 10:49	Keith_Hodges	Note Edited: 0008711
12-18-06 20:00	renggli	Note Added: 0008723
12-19-06 11:08	Keith_Hodges	Note Edited: 0008711
12-21-06 09:18	Keith_Hodges	Note Added: 0008735
12-23-06 04:58	Keith_Hodges	Note Edited: 0008711
01-11-07 00:30	Keith_Hodges	Note Edited: 0008711
01-10-09 00:14	Keith_Hodges	Note Deleted: 0008711
01-10-09 00:15	Keith_Hodges	Note Added: 0012910
01-10-09 00:15	Keith_Hodges	Status	new => resolved
01-10-09 00:15	Keith_Hodges	Fixed in Version	=> 3.11
01-10-09 00:15	Keith_Hodges	Resolution	open => fixed
01-10-09 00:15	Keith_Hodges	Assigned To	=> Keith_Hodges
01-10-09 00:16	Keith_Hodges	Note Added: 0012911
01-10-09 03:41	Keith_Hodges	Status	resolved => testing
10-03-09 19:34	Keith_Hodges	Status	testing => assigned
10-03-09 19:34	Keith_Hodges	Assigned To	Keith_Hodges => andreas

Relationships