Unit tests and external (json) resources

[Kim Shepherd]

Hi DSpace 7 devs (and all),

Is there a best practice for including external resources for unit tests?

In my case I want to test that some known valid JSON from the SHERPA API is parsed properly by our SHERPA integration code. It looks like the best way for me is to store it in src/test/data/.../ and refer to it in the resources/test-config.properties file, the way test.bitstream  is handled... but just thought I'd check this since there don't seem to be too many other precedents like that..

Any pointers appreciated!

Cheers

Kim

M: k...@shepherd.nz
T: @kimshepherd

W: www.shepherd.nz

0CCB D957 0C35 F5C1 497E CDCF FC4B ABA3 2A1A FAEC

[Kim Shepherd]

Whoops, meant to mention the other approach, in src/test/resources eg for mediafilter:

source = getClass().getResourceAsStream("wordtest.doc");

Perhaps that is actually more straight-forward..

[Mark H. Wood]

On Tue, May 05, 2020 at 02:22:28PM +1200, Kim Shepherd wrote:
> Whoops, meant to mention the other approach, in src/test/resources eg for
> mediafilter:
>
> source = getClass().getResourceAsStream("wordtest.doc");
>
> Perhaps that is actually more straight-forward..
>
> On Tue, 5 May 2020 at 14:14, Kim Shepherd <k...@shepherd.nz> wrote:
>
> > Hi DSpace 7 devs (and all),
> >
> > Is there a best practice for including external resources for unit tests?
> >
> > In my case I want to test that some known valid JSON from the SHERPA API
> > is parsed properly by our SHERPA integration code. It looks like the best
> > way for me is to store it in src/test/data/.../ and refer to it in the
> > resources/test-config.properties file, the way test.bitstream is
> > handled... but just thought I'd check this since there don't seem to be too
> > many other precedents like that..

I would prefer the src/test/resources approach if it is practical for
the unit under test. If a class' job is to open and read an external
file by name then we're stuck with passing the name, and the file then
has to live somewhere outside of any JAR. If the class' job is to
read a Stream then one may as well keep the test simple by using a
resource.

--
Mark H. Wood
Lead Technology Analyst

University Library
Indiana University - Purdue University Indianapolis
755 W. Michigan Street
Indianapolis, IN 46202
317-274-0749
www.ulib.iupui.edu

[Tim Donohue]

Hi Kim,

Just a quick note about validating/testing JSON (if that's what you also need to do).  For the DSpace 7 REST API, we use JsonPath heavily in tests to actually validate the structure of JSON returned.  Not sure if you'd need this for your tests, but wanted to mention it.  As a basic example, for testing the REST API v7, we've created a number of "Matcher" classes that simply validate the JSON structure returned by our REST API, looking for specific fields...e.g. https://github.com/DSpace/DSpace/blob/master/dspace-server-webapp/src/test/java/org/dspace/app/rest/matcher/GroupMatcher.java#L34

We've also occasionally created JSONObjects as test/sample JSON.  Here's an example of that: https://github.com/DSpace/DSpace/blob/master/dspace-server-webapp/src/test/java/org/dspace/app/rest/CollectionHarvestSettingsControllerIT.java#L100-L108

The main thing I'd think about trying to avoid, if I were you, is creating a hardcoded JSON file.  If you really really need that or if you are planning to just export it from the SHERPA API, that's OK. But, for code review & future bug fixes, it's a bit easier to read sometimes if you use Java to generate the JSON, rather than trying to get all the brackets lined up & closed in a manually created JSON file.  Just my two cents here though.

Tim

---

From: dspace...@googlegroups.com <dspace...@googlegroups.com> on behalf of Kim Shepherd <k...@shepherd.nz>
Sent: Monday, May 4, 2020 9:22 PM
To: DSpace Developers <dspace...@googlegroups.com>
Subject: [dspace-devel] Re: Unit tests and external (json) resources

 

--
All messages to this mailing list should adhere to the DuraSpace Code of Conduct: https://duraspace.org/about/policies/code-of-conduct/
---
You received this message because you are subscribed to the Google Groups "DSpace Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dspace-devel...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/dspace-devel/CAKZKfqr%2BRr%3Df8zj%3DxV61u27wJrv1GRv5tkP2sykB5v2Uq4GGpw%40mail.gmail.com.

[Kim Shepherd]

Thanks both

In this case the test is to prove that I can correctly parse SHERPA's JSON responses from their API and populate the java objects we use for SHERPA journal / policy / publisher handling later on.

So the JSON file is just an example response (one for a journal lookup, one for a publisher lookup) from SHERPA itself, saved to disk, so we can still test the JSON parsing without talking to the real API.

I probably could mock up a JSONObject as well, but this just feels like a more realistic test? It's not hand-crafted JSON at least :)

M: k...@shepherd.nz
T: @kimshepherd

W: www.shepherd.nz

0CCB D957 0C35 F5C1 497E CDCF FC4B ABA3 2A1A FAEC

To view this discussion on the web visit https://groups.google.com/d/msgid/dspace-devel/DM5PR2201MB1148587B9CAD7A63CDAAD122EDA70%40DM5PR2201MB1148.namprd22.prod.outlook.com.

[Tim Donohue]

Hi Kim,

That approach seems reasonable to me. 

Tim

---

From: Kim Shepherd <k...@shepherd.nz>
Sent: Tuesday, May 5, 2020 7:01 PM
To: Tim Donohue <tim.d...@lyrasis.org>; Mark H. Wood <mw...@iupui.edu>
Cc: DSpace Developers <dspace...@googlegroups.com>
Subject: Re: [dspace-devel] Re: Unit tests and external (json) resources

 

[Mark H. Wood]

On Wed, May 06, 2020 at 12:01:54PM +1200, Kim Shepherd wrote:
> Thanks both
> In this case the test is to prove that I can correctly parse SHERPA's JSON
> responses from their API and populate the java objects we use for SHERPA
> journal / policy / publisher handling later on.
> So the JSON file is just an example response (one for a journal lookup, one
> for a publisher lookup) from SHERPA itself, saved to disk, so we can still
> test the JSON parsing without talking to the real API.
> I probably could mock up a JSONObject as well, but this just feels like a
> more realistic test? It's not hand-crafted JSON at least :)

Yes, in this particular case it's probably best to use an actual
sample from the remote service, and certainly better than sending real
network requests during a unit test. OTOH we'll have to be sensitive
to changes in the actual response over time.