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

[Scott Prater]

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