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

[Dan Scott]

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