Thought I'd describe an extension I put together to run associated unit
tests while browsing any class, not just subclasses of TestCase. I had
to modify #queryCommand:. Perhaps the hooks should be folded into the
base? Or perhaps I could use ClosedCommandDescription to patch it in?
More on this later.
Background: The standard ClassHierachyBrowser and SystemBrowser now have
a "Tests" context menu item on the class list that lets you immediately
browse/run the unit tests when you're on a subclass of TestCase. Steve
Waring's SUnitBrowser extension adds the "Run Tests" menu item to the
top of the classes menu for even faster and easier selection. But it
still only applies when you're browsing a subclass of TestCase.
I wanted to extend this to work when browsing any class that had test
cases associated with it. I usually use a consistent naming convention,
so this would be easy to do. So for example, the Employee class has the
associated TestCase subclass named EmployeeTest.
First I modified ClassSelector>>queryCommand: to get rid of the explicit
test for subclasses. Down in the case for #testsMenu, after a series of
notNil tests it ended with:
class allSuperclasses anySatisfy: [:each | each name = #TestCase]
I changed this to:
class hasUnitTests
Did the same thing in Steve's extension, changing the end of the
queryBlock from "class includesBehavior: TestCase" to "class
hasUnitTests".
Then I added:
ClassDescription >> hasUnitTests
^self testCaseClass notNil
and:
TestCase class >> testCaseClass
^self
If one had a default:
ClassDescription >> testCaseClass
^nil
then I believe all of the above would just amount to a refactoring with
no change in behavior. But it would pull out of the queryCommand: method
the logic used to determine if a class has units tests associated with
it or not. So this much seems like a generally good thing to do. (tm)
I went on to put in:
ClassDescription >> testCaseClass
^Smalltalk at: (self instanceClass name , 'Test') asSymbol
ifAbsent: []
instead, which works with my naming of TestCase subclasses. To be safe,
I might want to add a further condition to this method to check that the
class that it finds is actually a subclass of TestCase.
At this point the menu items become enabled when browsing <someClass>
and there exists a <someClass>Test class. The only thing that remains to
get the browsing/running of the tests actually working is to add:
ClassDescription >> buildSuite
^self testCaseClass buildSuite
Does anyone else think that this a generally good set of changes?
Perhaps they could be folded into the base? I would think the only point
of contention would be the assumption of naming of testCaseClasses. I'd
suggest just having the ^nil default for #testCaseClass. People could
then simply override it in their application classes to answer each of
the associated TestCase subclasses. And I could just replace that one
simple method with my own version. :-) Beats having to make a change in
the middle of the [huge] queryCommand: method.
I had a thought, which I haven't investigated, that it might be possible
to use a ClosedCommandDescription to patch in a new version of the
"Tests" menu item without making any modifications to the existing
queryCommand: method. Seems like, even if it could be made to work, that
it would probably involve quite a bit more code than the above to get it
all set up. So even if it's possible, I'd still lobby for the above. <g>
Anyone care to render their opinion on any of this?
-------------------------------------------
Bill Dargel
[hidden email]
Shoshana Technologies
100 West Joy Road, Ann Arbor, MI 48105 USA
Locked
