Anonymous | Login | 03-07-2021 09:33 UTC |
Main | My View | View Issues | Change Log | Docs |
Viewing Issue Simple Details [ Jump to Notes ] | [ View Advanced ] [ 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 | |||||||
Reporter | Keith_Hodges | View Status | public | |||||||||
Assigned To | andreas | |||||||||||
Priority | normal | Resolution | fixed | |||||||||
Status | assigned | 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. | |||||||||||
Additional Information | ||||||||||||
Attached Files |
![]() ![]() |
|||||||||||
|
![]() |
|
(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 |
Mantis 1.0.8[^]
Copyright © 2000 - 2007 Mantis Group
102 total queries executed. 43 unique queries executed. |