Feature requests/wish list
| Author |
Message |
|
Randy Coulma
#1 / 13
|
 Feature requests/wish list Some ideas for tweaks or improvements. Once again, when I get some time, I'll take a crack at some of these. I post them here in case someone else thinks they're a good idea and gets there first. Or perhaps someone else has already done them and can point me to them. - Has anyone ported the RBSUnitExtensions package from VW7 to Dolphin?
I was missing it early on; now I've gotten used to SUnitBrowser, with a
minor tweak (see below). However, I think I would prefer this package
if it was available.
- VisualWorks has a feature where you can select a block of code in a
workspace pane and type Esc-(, Esc-", or Esc-' to surround the block of
code with (...), "...", or '...'. I don't remember off the top of my
head, but I would suspect that Esc-[ would work as well for [...].
There may be others. Has anyone done anything similar for Dolphin? How
hard would this be to add myself? I've not had a chance to look at it yet.
- VisualWorks has a feature where it prompts what to do with symbols it
doesn't recognize when accepting a method. It gives a set of choices -
missing some that I'd like to have, and including some that I never use.
I'd like to see the following choices: temporary variable, instance
variable, or new class (perhaps opening the new class dialog?). When
writing code test-first, it is common for me to try to create an
instance of a class that doesn't yet exist. When I do this, I have to
open another browser to define the class.
- Dragging and dropping a class in the Class Hierarchy pane of the
System Browser to change super-classes is a very nice feature. It would
be nicer still if hovering over a class with sub-classes would cause the
tree below that class to expand.
- SUnitBrowser/SUnit: It would be nice if there was a way to NOT run the
SUnitTest tests once I start writing my own tests. There's the two
failures in there to demonstrate the debugging features of SUnit, which
I don't need once I start writing my own tests.
I tried unloading the SUnitTests package, but the SUnitUI package
depends on it (trivially - look in the package browser). I know that
older versions of SUnit had an "isInProduction" method that would cause
those tests not to fail. That's dissppeared in the newer CampSmalltalk
versions of SUnit.
I know that I can delete that test from the list in SUnitBrowser, but
everytime I reset the test list, it comes back.
I've hacked around this for now (I marked SUnitTest as abstract so it
doesn't show up), but there's got to be a better solution.
One idea would be to add a property to SUnitBrowser for this.
Thanks again for a great toolset.
Randy
--
Randy Coulman
NOTE: Reply-to: address is spam-guarded. Reassemble the following to
reply directly:
rvcoulman at acm dot org
|
| Sat, 07 May 2005 14:38:04 GMT |
|
 |
|
Jeffrey Odel
#2 / 13
|
Feature requests/wish list The easiest way to change this is to change the method TestRunner>>onViewOpened and remove the last line (plus the ';' from the prior line, obviously) and save the image. This removes the dependency, and allows for the SUnitTest package to be removed. SUnitBrowser needs the rest of SUnit, so I can't do anything about it there.
I think TestRunner>>onViewOpened should be fixed as above - the TestRunner
still seems to function fine without it.
jlo
<snip>
Quote: > - SUnitBrowser/SUnit: It would be nice if there was a way to NOT run the > SUnitTest tests once I start writing my own tests. There's the two > failures in there to demonstrate the debugging features of SUnit, which > I don't need once I start writing my own tests. > I tried unloading the SUnitTests package, but the SUnitUI package
> depends on it (trivially - look in the package browser). I know that
> older versions of SUnit had an "isInProduction" method that would cause
> those tests not to fail. That's dissppeared in the newer CampSmalltalk
> versions of SUnit.
> I know that I can delete that test from the list in SUnitBrowser, but
> everytime I reset the test list, it comes back.
> I've hacked around this for now (I marked SUnitTest as abstract so it
> doesn't show up), but there's got to be a better solution.
<snip>
|
| Sat, 07 May 2005 20:41:47 GMT |
|
|
|
Joseph Pelrin
#3 / 13
|
Feature requests/wish list Quote:
> [snip] > - SUnitBrowser/SUnit: It would be nice if there was a way to NOT run
> the SUnitTest tests once I start writing my own tests. There's the
> two failures in there to demonstrate the debugging features of SUnit,
> which I don't need once I start writing my own tests.
> I tried unloading the SUnitTests package, but the SUnitUI package
> depends on it (trivially - look in the package browser). I know that
> older versions of SUnit had an "isInProduction" method that would
> cause those tests not to fail. That's dissppeared in the newer
> CampSmalltalk versions of SUnit.
Both of these problems have been corrected in the Camp Smalltalk SUnit 3.1 release. The two failing tests have been removed, and the TestRunner dependency on the SUnitTests package has been corrected. SUnit 3.1 will be released as soon as all dialect ports are finished -
or as soon as Blair and Andy roll out a new version of Solphin. For an
early release, you can grab the release candidates at
http://www.metaprog.com/Rosetta.
BTW - I've never run into an "isInProduction" method in any of the old
SUnit releases. All the fragmentation was the reason that Camp Smalltalk
decided to standardize...
--
--
Joseph Pelrine [ | ]
MetaProg GmbH
Web: http://www.metaprog.com
"If you don't live on the edge, you're taking up too much space" -
Doug Robinson
|
| Sat, 07 May 2005 22:25:46 GMT |
|
|
|
Randy Coulma
#4 / 13
|
Feature requests/wish list Quote:
> The easiest way to change this is to change the method
> TestRunner>>onViewOpened and remove the last line (plus the ';' from the
> prior line, obviously) and save the image. This removes the dependency, and
> allows for the SUnitTest package to be removed.
You're right. This would work nicely, but I like Joseph's answer better :-). Quote: > SUnitBrowser needs the rest of SUnit, so I can't do anything about it there.
> I think TestRunner>>onViewOpened should be fixed as above - the TestRunner
> still seems to function fine without it.
Yes, I realize it needs SUnit. I don't have a problem with that. It's just the tests I have a problem with - they always fail (by design). Randy
--
Randy Coulman
NOTE: Reply-to: address is spam-guarded. Reassemble the following to
reply directly:
rvcoulman at acm dot org
|
| Sun, 08 May 2005 00:04:14 GMT |
|
|
|
Randy Coulma
#5 / 13
|
Feature requests/wish list Quote:
> Both of these problems have been corrected in the Camp Smalltalk SUnit
> 3.1 release. The two failing tests have been removed, and the TestRunner
> dependency on the SUnitTests package has been corrected.
Nice. Thanks. Quote: > SUnit 3.1 will be released as soon as all dialect ports are finished - > or as soon as Blair and Andy roll out a new version of Solphin. For an > early release, you can grab the release candidates at > http://www.metaprog.com/Rosetta. > BTW - I've never run into an "isInProduction" method in any of the old
> SUnit releases. All the fragmentation was the reason that Camp Smalltalk
> decided to standardize...
IIRC, it was in the Dolphin port of 2.7 or so that I remember seeing it. The implementation was basically, "If I'm the only subclass of TestCase, then we're not in production, and we want to fail these tests. Otherwise, I'm in production and I'll shut up now." I believe the method was in the test class itself. Randy
--
Randy Coulman
NOTE: Reply-to: address is spam-guarded. Reassemble the following to
reply directly:
rvcoulman at acm dot org
|
| Sun, 08 May 2005 00:06:10 GMT |
|
|
|
Blair McGlasha
#6 / 13
|
Feature requests/wish list Randy Quote:
> ...
> - Has anyone ported the RBSUnitExtensions package from VW7 to Dolphin?
> I was missing it early on; now I've gotten used to SUnitBrowser, with a
> minor tweak (see below). However, I think I would prefer this package
> if it was available.
Can you give us an overview? Regards
Blair
|
| Sat, 14 May 2005 01:31:58 GMT |
|
|
|
Jeffrey Odel
#7 / 13
|
Feature requests/wish list I google'd (?) up this announcement that is a couple years old: http://www.bsug.org/pipermail/members/2000-January/000010.html
jlo
Quote: > Randy
> > ...
> > - Has anyone ported the RBSUnitExtensions package from VW7 to Dolphin?
> > I was missing it early on; now I've gotten used to SUnitBrowser, with a
> > minor tweak (see below). However, I think I would prefer this package
> > if it was available.
> Can you give us an overview?
> Regards
> Blair
|
| Sat, 14 May 2005 03:01:59 GMT |
|
|
|
Jeffrey Odel
#8 / 13
|
Feature requests/wish list Oh, and here is a picture. http://www.eli.sdsu.edu/courses/fall02/cs580/notes/testing/testing.ht...
ing6
jlo
Quote: > I google'd (?) up this announcement that is a couple years old: > http://www.bsug.org/pipermail/members/2000-January/000010.html
> jlo
> > Randy
> > > ...
> > > - Has anyone ported the RBSUnitExtensions package from VW7 to Dolphin?
> > > I was missing it early on; now I've gotten used to SUnitBrowser, with
a
> > > minor tweak (see below). However, I think I would prefer this package
> > > if it was available.
> > Can you give us an overview?
> > Regards
> > Blair
|
| Sat, 14 May 2005 03:07:43 GMT |
|
|
|
Randy Coulma
#9 / 13
|
Feature requests/wish list Quote:
> Randy
>>...
>>- Has anyone ported the RBSUnitExtensions package from VW7 to Dolphin?
>>I was missing it early on; now I've gotten used to SUnitBrowser, with a
>>minor tweak (see below). However, I think I would prefer this package
>>if it was available.
> Can you give us an overview?
Basically, when you have a class selection that includes 1 or more TestCase subclasses, you get an extra little bar at the bottom of the browser that has Run, Debug, and Profile buttons as well as a test-runner status bar. Click Run will run all of the tests in all of the selected TestCase subclasses, similarly for Debug and Profile. With the latest enhancements to SUnitBrowser, I'm more and more
satisfied with it, but right now I think my ideal would be to have a
button (and shortcut key) in the browser that would run all of the tests
(maybe only for the currently selected package(s) - I'm not sure about
that part yet) and show me the status right there. No window switching
required.
There is the right-click -> Tests -> Run option, but as I recall, it is
for one test class only, and it's too many mouse gestures.
Randy
--
Randy Coulman
NOTE: Reply-to: address is spam-guarded. Reassemble the following to
reply directly:
rvcoulman at acm dot org
|
| Sat, 14 May 2005 05:21:55 GMT |
|
|
|
Blair McGlasha
#10 / 13
|
Feature requests/wish list
Quote:
> > Can you give us an overview? > Basically, when you have a class selection that includes 1 or more
> TestCase subclasses, you get an extra little bar at the bottom of the
> browser that has Run, Debug, and Profile buttons as well as a
> test-runner status bar. Click Run will run all of the tests in all of
> the selected TestCase subclasses, similarly for Debug and Profile.
>...
Oh, whilst not wishing to diminish it, I thought it might be a bit more interesting than that. I like the idea of tests being run through a browser plugin, but I was wondering if it might be a bit cleverer and present one with the opportunity to run the tests while visiting the application class rather than the TestCase. I can think of some ways to do this, but I was hoping someone else had got there first. I recall that someone posted info here about a goodie to do this sort of thing, but it required that the link between a TestCase and the class(es) it tests be established explicity by defining a method on the TestCase. I think it would be nice if the classes covered by a TestCase could be inferred in the absence of the explicit cross-reference. Regards
Blair
|
| Mon, 16 May 2005 06:33:44 GMT |
|
|
|
Randy Coulma
#11 / 13
|
Feature requests/wish list Quote:
> Oh, whilst not wishing to diminish it, I thought it might be a bit more
> interesting than that. I like the idea of tests being run through a browser
> plugin, but I was wondering if it might be a bit cleverer and present one
> with the opportunity to run the tests while visiting the application class
> rather than the TestCase. I can think of some ways to do this, but I was
> hoping someone else had got there first. I recall that someone posted info
> here about a goodie to do this sort of thing, but it required that the link
> between a TestCase and the class(es) it tests be established explicity by
> defining a method on the TestCase. I think it would be nice if the classes
> covered by a TestCase could be inferred in the absence of the explicit
> cross-reference.
AFAIK, it's not that smart. It could be improved. The main advantage is the ability to do it right from the browser. I like your idea above about associating classes with their tests.
Given that, plus a variation on the sunitBrowserAutoReset package, I can
see setting things up so that, any time you make a change to either a
test or a tested class (or methods within them), the tests are
automatically re-run.
There's people talking about variations of this for Eclipse, but I could
see it working really well in Smalltalk.
Randy
--
Randy Coulman
NOTE: Reply-to: address is spam-guarded. Reassemble the following to
reply directly:
rvcoulman at acm dot org
|
| Mon, 16 May 2005 06:51:22 GMT |
|
|
|
Bill Darge
#12 / 13
|
Feature requests/wish list Quote:
> Oh, whilst not wishing to diminish it, I thought it might be a bit more
> interesting than that. I like the idea of tests being run through a browser
> plugin, but I was wondering if it might be a bit cleverer and present one
> with the opportunity to run the tests while visiting the application class
> rather than the TestCase. I can think of some ways to do this, but I was
> hoping someone else had got there first. I recall that someone posted info
> here about a goodie to do this sort of thing, but it required that the link
> between a TestCase and the class(es) it tests be established explicity by
> defining a method on the TestCase. I think it would be nice if the classes
> covered by a TestCase could be inferred in the absence of the explicit
> cross-reference.
I've been using a simple extension that I've found rather useful. After adopting the convention that application class Foo would have its TestCase class named FooTest, the following handful of methods takes care of it. And having added F5 as an accelerator to Steve Waring's
SUnitBrowserIDEExtensions (and changed the queryBlock to use #hasUnitTests), I
can be on say class Customer in a class or system browser, simply hit F5 and
have the CustomerTest suite run and displayed in an SUnitBrowser. The
functionality is pretty close to having it embedded right in the class browser.
The shortcoming is the one-to-one mapping between application classes and
testCase classes. Perhaps though it would be a good default, and then add the
ability to explicitly associate a TestCase class with a cluster of application
classes (or vise versa) where needed?
Regards,
-Bill
!ClassDescription methodsFor!
buildSuite
^self testCaseClass buildSuite!
hasUnitTests
^self testCaseClass notNil!
testCaseClass
^Smalltalk at: (self instanceClass name , 'Test') asSymbol ifAbsent: []! !
!TestCase class methodsFor!
testCaseClass
^self! !
-------------------------------------------
Shoshana Technologies
100 West Joy Road, Ann Arbor, MI 48105 USA
|
| Mon, 16 May 2005 08:32:53 GMT |
|
|
|
Chris Uppa
#13 / 13
|
Feature requests/wish list Blair, Quote: > I like the idea of tests being run through a browser
> plugin, but I was wondering if it might be a bit cleverer and present one
> with the opportunity to run the tests while visiting the application class
> rather than the TestCase.
I'm probably not using the SUnit framework in the way that it's makers intended (for one thing, I use it for regression tests not unit tests), but I find that when I use it at all there a strong tendency for the relationship between classes and test case classes to be many-to-many. For instance I'll have several test case classes subclassed off one "abstract" test class, that all run essentially the same test code, but with different setups. Contrariwise, any one of my tests (or test classes) is attempting to look at one aspect of the functionality, and so will actually be testing the interactions between several -- possibly many -- classes. Accordingly, for any such feature to be useful *to me* (and even I don't
suggest that that should be you highest priority ;-) it'd need to be much more
loosely coupled than (e.g.) some relationship between classnames. A rather
broad-brush approach would be to work at the level of packages. Given a
package named 'CU X', if anything in it has changed then all packages with
names ending in 'Test' or 'Tests' that are dependants on 'CU X' would be
considered to be in need of re-validation.
A very tentative suggestion, extending this, is that it might (*might*) work
out well if there was a new subclass of Package that knew that it held
test cases, knew whether it was up-to-date and "all green", and knew (or could
be specialised to know) what classes/methods/packages/etc it tested.
-- chris
|
| Mon, 16 May 2005 17:57:52 GMT |
|
| |
|
