Testing a package

Hi,

How can I run all the tests in a given package using the SUnit
Browser?  I doesn't seem to allow you to group tests by package...

Fernando Rodriguez wrote:
> Hi,
>
> How can I run all the tests in a given package using the SUnit
> Browser?  I doesn't seem to allow you to group tests by package...

I have code for this. Let me dig it out and clean it up a bit, and I'll
post it later today. OK?

Cheers
Joseph

On Wed, 07 Sep 2005 12:15:05 +0200, Joseph Pelrine <[hidden email]>
wrote:

>Fernando Rodriguez wrote:
>> Hi,
>>
>> How can I run all the tests in a given package using the SUnit
>> Browser?  I doesn't seem to allow you to group tests by package...
>
>I have code for this. Let me dig it out and clean it up a bit, and I'll
>post it later today. OK?

Done, thanks

Fernando Rodriguez wrote:
So, here's some code. It works correctly with the SUnit TestRunner, but
not (yet) with the SUnitBrowser. This has to do with the underlying
model of the browser. If someone wants to work on fixing this, I'd be
happy to help as much as I can.

It's pretty easy to use this. Simply subclass AllTestsInPackageTestCase
and override the class method #packageToTest to return the name of the
package you want to generate a suite from. That's it. Have fun...

Cheers
Joseph

***********************

| package |
package := Package name: 'TestSuiteFromPackage'.
package paxVersion: 0;
        basicComment: ''.


package classNames
        add: #AllTestsInPackageTestCase;
        add: #TestSuiteFromPackageTestCase;
        yourself.

package binaryGlobalNames: (Set new
        yourself).

package globalAliases: (Set new
        yourself).

package allResourceNames: (Set new
        yourself).

package setPrerequisites: (IdentitySet new
        add: '..\..\Object Arts\Dolphin\Base\Dolphin';
        add: 'SUnit';
        yourself).

package!

"Class Definitions"!

TestCase subclass: #AllTestsInPackageTestCase
        instanceVariableNames: ''
        classVariableNames: ''
        poolDictionaries: ''
        classInstanceVariableNames: ''!
TestCase subclass: #TestSuiteFromPackageTestCase
        instanceVariableNames: ''
        classVariableNames: ''
        poolDictionaries: ''
        classInstanceVariableNames: ''!

"Global Aliases"!


"Loose Methods"!

"End of package definition"!

"Source Globals"!

"Classes"!

AllTestsInPackageTestCase guid: (GUID fromString:
'{DAF7CEC1-5602-45DF-9E46-B38A3C61EE5E}')!
AllTestsInPackageTestCase comment: ''!
!AllTestsInPackageTestCase categoriesForClass!Unclassified! !
!AllTestsInPackageTestCase class methodsFor!

buildSuite
        ^self suiteFromPackageNamed: self packageToTest!

packageToTest
        ^'SUnitTests'!

suiteFromPackageNamed: packageName
        | suite testClasses package |
        package := PackageManager current packageNamed: packageName.
        suite := self suiteClass named: package name , ' package test suite'.
        testClasses := package classes select: [:each | each isKindOf: TestCase
class].
        testClasses
                do: [:each | each isAbstract ifFalse: [suite addTest: each
buildSuiteFromSelectors]].
        ^suite! !
!AllTestsInPackageTestCase class categoriesFor: #buildSuite!instance
creation!public! !
!AllTestsInPackageTestCase class categoriesFor: #packageToTest!instance
creation!public! !
!AllTestsInPackageTestCase class categoriesFor:
#suiteFromPackageNamed:!instance creation!public! !

TestSuiteFromPackageTestCase guid: (GUID fromString:
'{7EC60A8D-D7ED-456B-B4F7-1839A235AAB6}')!
TestSuiteFromPackageTestCase comment: ''!
!TestSuiteFromPackageTestCase categoriesForClass!Unclassified! !
!TestSuiteFromPackageTestCase methodsFor!

testMethodsInSUnitTestsPackage
        | suite result |
        suite := AllTestsInPackageTestCase suiteFromPackageNamed: 'SUnitTests'.
        self assert: suite tests size = 4.
        result := TestResult new.
        suite run: result.
        self assert: result passedCount = 23! !
!TestSuiteFromPackageTestCase categoriesFor:
#testMethodsInSUnitTestsPackage!public!running! !

"Binary Globals"!

"Resources"!

On Thu, 08 Sep 2005 18:55:49 +0200, Joseph Pelrine <[hidden email]>
wrote:

>So, here's some code. It works correctly with the SUnit TestRunner, but
>not (yet) with the SUnitBrowser. This has to do with the underlying
>model of the browser. If someone wants to work on fixing this, I'd be
>happy to help as much as I can.
>

<snip>

Thanks!

Hello all,

> So, here's some code. It works correctly with the SUnit TestRunner, but
> not (yet) with the SUnitBrowser. This has to do with the underlying
> model of the browser. If someone wants to work on fixing this, I'd be
> happy to help as much as I can.

You are welcome to use or raid my filtered browser goodie, which
transparently creates test suites for SUnitBrowser.

Have a good one,

Bill


--
Wilhelm K. Schwab, Ph.D.
[hidden email]

Bill Schwab wrote:
Thanks for the offer, Bill. Where do I find it? Also, I never heard any
comment from you on the TestResource paper...

Cheers
Joseph

Joseph,

> Thanks for the offer, Bill. Where do I find it?

It is in my goodies, in AcmeClassBrowser.pac.


 > Also, I never heard any
> comment from you on the TestResource paper...

DOH!!!!  Sorry about that.  I started to give it the review it deserves,
and then got torn away from it.

You have done a nice job of describing the topic.  However, I am stuck
that the entire framework is, or at least appears to be, too complicated
for its own good.  That extends to resources.  For example, in an ideal
world, I would want the tests to know which resources they need vs. my
needing to tell them.  Resources could be singletons, and could have
some layers of default cleanup: per session, never, other stuff in
between that might make sense.

Long ago (in computer years anyway), I read something that suggested
that GLORP used test resources to create huge schemas, and that work was
done lazily or on demand vs. being done routinely.  It sounded great,
but I have never grasped how to get that level of service from the
framework.  In fairness to the framework, I've never much worked at it.

Let me know if this sounds insightful (in which case I am probably done
for now) or totally off the wall (in which case I need to re-read your
documentation and give it another shot).

Apologies again for letting it get lost in the stack.

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]

Bill Schwab wrote:
> Joseph,
>
>> Thanks for the offer, Bill. Where do I find it?
>
>
> It is in my goodies, in AcmeClassBrowser.pac.
And where do I find your goodies?
Aren't you following contrary goals here? On the one side, you say that
the framework is too complicated for its' own good. On the other side,
you want it to automagically figure out which resources the tests need.
Sure, we could implement that, but the amount of meta-level magic
necessary for such DWIM functionality would be much greater than what's
there right now.

> Long ago (in computer years anyway), I read something that suggested
> that GLORP used test resources to create huge schemas, and that work was
> done lazily or on demand vs. being done routinely.  It sounded great,
> but I have never grasped how to get that level of service from the
> framework.  In fairness to the framework, I've never much worked at it.
The TestResources framework was developed for GLORP! Alan Knight asked
me if it was possible to make the miminal change/addition necessary to
SUnit to support resources. The implementation was reviewed and approved
by him and IIRC 10 other heavy-hitters. We thought that this was enough
review and criticism to get the resource support down to the simplest
possible level. Maybe we were wrong.

> Let me know if this sounds insightful (in which case I am probably done
> for now) or totally off the wall (in which case I need to re-read your
> documentation and give it another shot).
 >
> Apologies again for letting it get lost in the stack.
No problem. Thanks for your input. I'm constantly trying to improve the
quality of the code I write, and constructive criticism is always
helpful there. May I suggest, though, that you re-read the document
while sitting at the computer and typing the example in? Resources
really are much simpler to use than you make them out to be.

If anyone else is interested, the draft TestResource paper, as well as a
number of other goodies, are available at http://www.metaprog.com/ESUG/.

Cheers
Joseph

Joseph,

> Aren't you following contrary goals here? On the one side, you say that
> the framework is too complicated for its' own good.

IMHO, yes.  In general, there are too many entry points, and too many
ways to accomplish any one task.  If some of the redundancy is a
compatibility layer for one or another project or group of users, then
it might be put in a separate package/change-set/parcel for clarity.

Early on, I looked at SUnit and ended up building my own framework that
was friendly to package level testing and was (overly) simple.  The
SUnitBrowser was the thing that got me to take another look at SUnit.


 > On the other side,
> you want it to automagically figure out which resources the tests need.
> Sure, we could implement that, but the amount of meta-level magic
> necessary for such DWIM functionality would be much greater than what's
> there right now.

I suspect that a combination of singleton (or similar concept) test
resouces combined with a clear pattern for their use (perhaps a TestCase
method to access them) would make it almost as easy as checking the
#test* methods against references to the subclasses of TestResource.
Failing that, a TestCase subclass could override #requiredResources (or
whatever it's called) to add anything that slipped past the detection grid.



> No problem. Thanks for your input. I'm constantly trying to improve the
> quality of the code I write, and constructive criticism is always
> helpful there. May I suggest, though, that you re-read the document
> while sitting at the computer and typing the example in?

Fair enough.  Please don't take offense at the following: I simply do
not have time right now.  That will change.



 > Resources
> really are much simpler to use than you make them out to be.

I don't doubt it.  In fact, SUnit is a lot simpler than the readily
available docs (at least back when I was learning) make it out to be.

Have a good one,

Bill


--
Wilhelm K. Schwab, Ph.D.
[hidden email]

Bill Schwab wrote: I can't quite follow you here, but if you have something that works for
you, then don't change it.

Now I really don't follow you. What you describe is exactly what we have:
- a singleton implementation of resources. Subclass from TestResource,
implement #setUp and #tearDown (presuming you need them), and your
resource wrapper is finished.
- a TestCase method to reference them. This is class method #resources.
This is called early on by the framework because I want to know *before*
  the tests are run if all resources are OK. I don't want to call a
TestCase method later on and then say "oops, I can't run these tests
because a resource isn't available".
The upcoming book on SUnit will be even better...

Cheers
Joseph