|Anonymous | Login||05-16-2021 10:09 UTC|
|Main | My View | View Issues | Change Log | Docs|
|Viewing Issue Advanced Details [ Jump to Notes ]||[ View Simple ] [ Issue History ] [ Print ]|
|ID||Category||Severity||Reproducibility||Date Submitted||Last Update|
|0005639||[Squeak] SUnit||feature||always||12-14-06 05:38||10-03-09 19:34|
|ETA||none||Fixed in Version||3.11||Product Version||3.9|
|Summary||0005639: proposed improvements to SUnit specification of suites|
|Description||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.|
|Steps To Reproduce|
SUnit-kph.38.mcz [^] (26,441 bytes) 12-14-06 07:15
SUnitGUI-kph.13.mcz [^] (13,001 bytes) 12-14-06 07:15
(0008712 - 275 - 299 - 299 - 299 - 299 - 299)
- 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)
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)
> 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)
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)
|Currently this code is available via Universes and Sake/Pacakges 'SUnit-improved'|
(0012911 - 32 - 32 - 32 - 32 - 32 - 32)
|Is part of the release-candidate|
|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|
| Mantis 1.0.8[^]
Copyright © 2000 - 2007 Mantis Group
102 total queries executed.|
43 unique queries executed.