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

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

"Randy Coulman" <[hidden email]> wrote in message
news:arcm8c$gl9u0$[hidden email]...
<snip> <snip>

Randy Coulman wrote:
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
Email: [hidden email]
Web:   http://www.metaprog.com

"If you don't live on the edge, you're taking up too much space" -
Doug Robinson

Jeffrey Odell wrote:
> 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
:-).

> 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

Joseph Pelrine wrote:
> 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.

> 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

Randy

You wrote in message news:arcm8c$gl9u0$[hidden email]...
> ...
> - 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

I google'd (?) up this announcement that is a couple years old:

http://www.bsug.org/pipermail/members/2000-January/000010.html

jlo
"Blair McGlashan" <[hidden email]> wrote in message
news:artmvk$lvi0u$[hidden email]...

Oh, and here is a picture.

http://www.eli.sdsu.edu/courses/fall02/cs580/notes/testing/testing.html#Head
ing6

jlo

"Jeffrey Odell" <[hidden email]> wrote in message
news:[hidden email]... a

Blair McGlashan wrote:
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

"Randy Coulman" <[hidden email]> wrote in message
news:aru49l$ln6du$[hidden email]...
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

Blair McGlashan wrote:
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

Blair McGlashan wrote:

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! !

-------------------------------------------
Bill Dargel            [hidden email]
Shoshana Technologies
100 West Joy Road, Ann Arbor, MI 48105  USA

Blair,

> 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