[OPEN-ILS-DEV] writing tests for OpenSRF methods?

[Lori Bowen Ayre]

HI Scott,

Sounds like you are doing some great stuff!  For testing purposes, please
feel free to reach out to Brian Feifarek who maintains some of the demo
servers.  He loaded some demo data on the servers (there was some attempt
to have the same data on each of the demo servers.)  I don't know if that
data is useful. But Brian may be able to help you out with getting a test
server server in place.

I'm copying him on this email.

Lori

On Tue, Dec 27, 2011 at 5:55 PM, Scott Prater <sprater at gmail.com> wrote:

> Thanks, Dan.  I can't promise I'll have any integration tests in place
> by the time the bell chimes midnight on Dec. 31st, but I'll plan on
> having something ready not too long afterwards.
>
> I'll create a subdir under OpenILS/tests and begin work there.
>
> -- Scott
>
> On Tue, Dec 27, 2011 at 5:35 PM, Dan Scott <dan at coffeecode.net> wrote:
> > On Tue, Dec 27, 2011 at 05:12:26PM -0600, Scott Prater wrote:
> >> I've made the changes needed in the admin client (statistical category
> >> editor) to implement the enhancements to patron statistical categories
> >> ( see the proposal at
> >>
> http://evergreen-ils.org/dokuwiki/doku.php?id=dev:proposal:patron_statistical_categories
> >> ).  I did some pretty thorough and mind-crushingly dull manual testing
> >> in the staff admin client to make sure that everything behaved as
> >> expected in all the possible combinations I could think of different
> >> org units, categories, entries, etc.
> >
> > Wow! At first glance that looks like an impressively well-scoped and
> > thought-out chunk of work!
> >
> >> What I'd really like to do is write tests for the OpenSRF methods I
> >> created that simulate as closely as possible the requests made by the
> >> javascript to the OpenSRF backend, so that I can make sure I cover all
> >> the possible use cases, get expected responses, and be able to rerun
> >> the tests whenever any changes are made.
> >>
> >> My tests would do all the things normal things tests do:  seed the
> >> database with test data, execute the methods with some mock objects,
> >> and compare the responses to other mock objects, then delete the test
> >> data from the database.
> >>
> >> Where would be the best place to put such tests in the source tree?
> >
> > For functional verification tests like this that would require a
> > complete running system, I think a subdirectory under Open-ILS/tests
> > would be perfectly appropriate. If you need seed data for bib records,
> > copies, call numbers, located URIs, monograph parts, and conjoined items
> > you might find Open-ILS/tests/datasets/concerto.sql useful. Sounds like
> > that's not the focus of your current efforts, but perhaps a similar
> > approach would be useful for seeding the data you need - particularly if
> > you need to create "historical" data such as past circulation history,
> > etc, that might not be as easy to create using strict OpenSRF API calls.
> >
> >> What would be the preferred way to invoke them?  Are there any
> >> examples in the current source I can use as a model for writing and
> >> executing my own tests?  Ideally, this would become part of a larger
> >> framework of tests that would eventually completely cover the entire
> >> Evergreen source code.
> >
> > I can't say they're a perfect model for you in that the existing tests
> > only exercise static code (that is, when they do anything more than just
> > ensuring that the code is actually valid syntax), but if you're
> > comfortable with Perl (as you appear to be), there are basic unit tests
> > using the Test::More framework in the Open-ILS/src/perlmods/t directory.
> >
> > (Also, can I say that getting a solid chunk of system tests into the
> > code base would be the best end-of-year present for Evergreen that I can
> > imagine?)
> >
> > Dan
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://libmail.georgialibraries.org/pipermail/open-ils-dev/attachments/20111228/4a4ba7ca/attachment.htm>