[OPEN-ILS-DEV] Putting the community's QA money where our dev mouth is

[Mike Rylander]

Dan,

I understand the process of building mock environments, but thanks.

It's my understanding that concerto is intended to be a valid test
environment, so I decided to go with that.  Is that not the case?

As I mentioned in IRC, changing my most recent test to create a mock
env would be fine, of course, and might even be a good learning tool
for someone else interested in working with pgTAP tests in EG.  But,
if nobody else gets around to it, I'll try to find time to remove the
dependency on concerto data.  It'll be lower priority than other tests
or new development, though, since the test exists now ... and that's
100% more existing than it was doing before. :)

--miker


On Tue, Nov 5, 2013 at 1:53 PM, Dan Scott <dan at coffeecode.net> wrote:
> On Tue, Nov 5, 2013 at 1:41 PM, Mike Rylander <mrylander at gmail.com> wrote:
>> CORRECTION: the commit hash is
>> 3e7f6f1503938e3e5a1cfe3bd90eaa8f021a0d48 ... I failed to fetch before
>> attempting to pick. Sorry!
>
> Hey Mike:
>
> It looks like that test assumes that the concerto sample records have
> been loaded, which means we can't run it on a production system.
>
> What I've done in my tests, instead, is insert the desired record with
> a known-and-entirely-improbable record ID, then tested against that.
> As we're using an explicit ID, the sequence doesn't get touched, and
> as the test occurs within a transaction, the record and all derived
> rows get rolled back at the end.
>
> To make my approach more airtight, I suppose I should test for the
> existence of a record with the entirely-improbable ID first, and skip
> the test if that record ID for some reason exists...



-- 
Mike Rylander
 | Director of Research and Development
 | Equinox Software, Inc. / Your Library's Guide to Open Source
 | phone:  1-877-OPEN-ILS (673-6457)
 | email:  miker at esilibrary.com
 | web:  http://www.esilibrary.com