Good test resource example/tutorial?

Hello all,

I am soon going to be throwing together (pardon me, I meant to say
thoughtfully engineering<g>) a new system.  It screams for relational
storage, and will rely on MySQL for it.

I have never utilized test resources, but gather that this might be a
good place to start, at least based on responses to an earlier question
of mine.  Is there anything I should read to get up to speed?

Have a good one,

Bill

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

Hey Bill,

> I have never utilized test resources, but gather that this might be a
> good place to start, at least based on responses to an earlier question
> of mine.  Is there anything I should read to get up to speed?

Am I the only one who sort of draws a blank as to what "test resources"
encompasses?

My initial thought is the test resource is unit tests that run against a
test database? Like I said, not really sure what you mean.

Hi Bill,

I have also not understood what do you mean by test-resource, so no
suggestions on that from me. But I am curious, how do you intend to conect
to MySQL? Through mysql odbc driver, and Dolphin ODBC classes? Or by writing
dolphin wrappers around MySQL client C library? Or by sitting on  the socket
and playing MySQL wire protocol like that VW implementation that floats
around?

Thanks!

rush
--
http://www.templatetamer.com/
http://www.folderscavenger.com/

"Bill Schwab" <[hidden email]> wrote in message
news:d1qgia$1fl6$[hidden email]...

Rush,

> I have also not understood what do you mean by test-resource, so no
> suggestions on that from me.

Don't take my word for it :)  Have a look at the SUnit Resource Browser
in your nearest D4 or D5.x image.  Google seems aware of the concept too.


 > But I am curious, how do you intend to conect
> to MySQL? Through mysql odbc driver, and Dolphin ODBC classes? Or by writing
> dolphin wrappers around MySQL client C library? Or by sitting on  the socket
> and playing MySQL wire protocol like that VW implementation that floats
> around?

ODBC.  If the newer ODBC drivers give you any trouble (IIRC, it was
#tables that blew up), try changing the "No catalog" option.  It looked
to me as though MyODBC was in error, and I added a note to an existing
bug report.

Have a good one,

Bill


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

On Wed, 23 Mar 2005 11:49:15 -0500, Bill Schwab
<[hidden email]> wrote:

>Rush,
>
>> I have also not understood what do you mean by test-resource, so no
>> suggestions on that from me.
>
>Don't take my word for it :)  Have a look at the SUnit Resource Browser
>in your nearest D4 or D5.x image.  Google seems aware of the concept too.

If that's what you're looking for, then these are the relevant entries
of my singleton instance of ToReadQueue (implemented with weak
references, getting horribly long and in dare need of garbage
collection ;-):

http://homepage.ntlworld.com/ted.bracht/id23.htm
http://urlmini.us/?i=582

I wonder if this can be extended to automagicly checking the
consistence of GUIs.  For instance, if conditions x, y and z apply,
does the GUI look ok?

In a previous application (that had a lot of state) this was the most
boring and one of the most time-consuming QA tasks. It would be great
if this could be automated. The problem is how to define, if possible
in a declarative way, what 'look ok' means in every possible
situation...


>ODBC.  If the newer ODBC drivers give you any trouble (IIRC, it was
>#tables that blew up), try changing the "No catalog" option.  It looked
>to me as though MyODBC was in error, and I added a note to an existing
>bug report.

Hhmm... Why not OmniBase? Has onyone used it for non-trivial stuff?
How does it scale?

Fernando,

> If that's what you're looking for, then these are the relevant entries
> of my singleton instance of ToReadQueue (implemented with weak
> references, getting horribly long and in dare need of garbage
> collection ;-):
>
> http://homepage.ntlworld.com/ted.bracht/id23.htm
> http://urlmini.us/?i=582

Interesting stuff.  To be honest, I'm hoping for "Everything you need to
know about TestResource, and nothing you don't" on a page and half :)
Regardless of success or failure, I suspect you've just sold a book or two.


>>ODBC.  If the newer ODBC drivers give you any trouble (IIRC, it was
>>#tables that blew up), try changing the "No catalog" option.  It looked
>>to me as though MyODBC was in error, and I added a note to an existing
>>bug report.
>
>
> Hhmm... Why not OmniBase? Has onyone used it for non-trivial stuff?
> How does it scale?

This problem indeed screams for relational storage (something I do not
say often or lightly), and I have sufficient control of MySQL to make it
tolerable.

Have a good one,

Bill

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

"Bill Schwab" <[hidden email]> wrote in message
news:d1s649$l1c$[hidden email]...
> Don't take my word for it :)  Have a look at the SUnit Resource Browser
> in your nearest D4 or D5.x image.  Google seems aware of the concept too.

Ok, now I have done a bit of reading on it, and it surely looks like
database connection is reasonable candidate for test resource. Thanks for
pointing me to it, since it adresses some cases where unit testing is harder
to accomplish. On that harder to accomplish note, I have still not found a
way to apply reasonably unit testing on distributed systems, with a lots of
state and interconnections and interaction.

> ODBC.  If the newer ODBC drivers give you any trouble (IIRC, it was
> #tables that blew up), try changing the "No catalog" option.  It looked
> to me as though MyODBC was in error, and I added a note to an existing
> bug report.

thnx, I am not using it at time (but it seems tempting), I am just curious
how it works.

rush
--
http://www.templatetamer.com/
http://www.folderscavenger.com/

"rush" <[hidden email]> writes:

For what it's worth, my impression of unit testing practices in XP is
that you would mock/stub out the actual distribution so that you can
simulate whatever state/situations you want. You could then make a
coarse grained test that actually tests real, live distribution
(acceptance test).

On 24 Mar 2005 12:28:12 +0100, Syver Enstad <[hidden email]> wrote:


>For what it's worth, my impression of unit testing practices in XP is
>that you would mock/stub out the actual distribution so that you can
>simulate whatever state/situations you want. You could then make a
>coarse grained test that actually tests real, live distribution
>(acceptance test).

Could you elaborate on this, please?

Thanks

Rush,

> Ok, now I have done a bit of reading on it, and it surely looks like
> database connection is reasonable candidate for test resource. Thanks for
> pointing me to it, since it adresses some cases where unit testing is harder
> to accomplish. On that harder to accomplish note, I have still not found a
> way to apply reasonably unit testing on distributed systems, with a lots of
> state and interconnections and interaction.

If you dig around in the archives, you will find some recommendations
made to me re test resources for a socket-based system.  I test only
local connections, but do create, use, and destroy sockets in the
resulting tests, which now work.  For that system, I decided against
test resources because they seemed to be offering a way to avoid some of
the fun of startup and shutdown.  After some careful study of the
failures and a little beneficial refactoring, the tests pass without the
"cheat".

My indirect and incomplete (you've been warned<g>) impression of GLORP's
  tests is that they create extensive databases for testing, and that
test resources are used and it is very likely appropriate to do so.


>>ODBC.  If the newer ODBC drivers give you any trouble (IIRC, it was
>>#tables that blew up), try changing the "No catalog" option.  It looked
>>to me as though MyODBC was in error, and I added a note to an existing
>>bug report.
>
>
> thnx, I am not using it at time (but it seems tempting), I am just curious
> how it works.

Very well in my experience.  However, I don't ask too much of relational
databases, so I'm easy to please.  I also like the fact that their lead
developers have been known to take personal responsibility for defects
in their products.

Have a good one,

Bill


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

Dear Bill,

> I am soon going to be throwing together (pardon me, I meant to say
> thoughtfully engineering<g>) a new system.  It screams for relational
> storage, and will rely on MySQL for it.
>
> I have never utilized test resources, but gather that this might be a
> good place to start, at least based on responses to an earlier question
> of mine.  Is there anything I should read to get up to speed?

1) The 'Second SUnit BoF on TestResources' is written up on page 25 - 28 of
my ESUG2003 report, which you can find at
http://wiki.eranova.si/esug/DOWNLOAD/nfrESUG2003reportPublic.pdf.  This has
sensible remarks re:

 - distinguishing resource example code from resource test code in the
SUnitTests

 - how to respect the class-instance-singleton pattern when referencing
resources

 - what the minimal pattern is.  To grasp resources, just follow the code
path

    TestResource class>>isAvailable
        TestResource class>>current
            TestResource >>initialize
                TestResource>>setUp
and
    TestResource class>>reset
        TestResource>>tearDown

and then see where #isAvailable is being called, i.e. in TestSuite>>run and
in the debug methods (also see (4) below).

The resource encapsulates what the user would otherwise do:

    * Before running a test suite, check status and/or create what is needed
    * Run a bunch of tests
    * After suite has finished, tear the resources down again

Normally, all you need to so is code the resource setUp and tearDown, and
then add the class to the class-side of tests that need it.  What pattern
you use is up to you;  just think about what you as a user would do if the
resource (e.g. a database session) was not there:

 * The most usual pattern is Lazy setUp / Hard tearDown:  #setUp looks for a
suitable existing database session (instance-side #isAvailable should
implement the check) and creates it if there is none, tearDown kills it
regardless.

 * If the system is happy with multiple DB sessions, you might want Hard
setUp and tearDown:  never mind checking, just create a test-specific
session and tear it down.

 * You can implement Lazy setUp / Hard tearDown by having #initialize check
instance-side #isAvailable and only call #setUp if it fails.  I have a
subclass 'InvariantTestResource' that uses this to capture whether the test
created the resource and so to avoid tearing down the resource if it did not
create it.  This can save time when you are rapidly switching between
running tests and executing workspace code that also needs the resource.  (I
have wondered if this should become the standard pattern.)

2) Last I looked, I felt that the SUnitBrowser's resource UI was not
handling resources as I would expect.  Resources are not intended for user
intervention or for test-run-independent setUp or tearDown.   Once a
resource has been defined, you should never have do anything re setting it
up or tearing it down, nor should you need a UI to see its state;  the state
is what the current test run state requires.

3) The CompetingResource pattern I mention in my conference report of the
BoF is now tested and implemented.  I've sent it to Joseph Pelrine for
review and plan to drop it into the Cincom Open Repository soon.  I would
expect the code to be Dolphine-compatible.  So if

    - you expect to write tests that run against different databases, for
each of which you wil have a resource (e.g. via a DatabaseSession abstract
superclass with several subclasses, one per database)

    - your application can only connect to one database at a time

    - you will want to run suites that contain different-database-using
tests (e.g. in a nightly run of all tests)

then let me know and I'll send you the code (as parcel or file-out, tell me
what you wish).  If you will only be running all tests against the same
database at any one time, don't bother asking for this as you will not need
it.

4) Be aware that in standard SUnit, TestSuite>>run checks resources and so
does debugging, but TestCase>>run does not!!!  With most SUnit UIs this is
not an issue but if you do programmatic test case handling it can sometimes
surprise you.  (I believe this is simply an accidental omission, i.e. that
TestCase and TestSuite should be wholly polymorphic in their response to
#run, and will discuss changing it in the next version of SUnit at this
year's Smalltalk Solutions).

HTH.

            Yours faithfully
                Niall Ross