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.dono...@lyrasis.org>; Mark H. Wood <mw...@iupui.edu> Cc: DSpace Developers <dspace-devel@googlegroups.com> Subject: Re: [dspace-devel] Re: Unit tests and external (json) resources 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<mailto:k...@shepherd.nz> T: @kimshepherd W: www.shepherd.nz<http://shepherd.nz> 0CCB D957 0C35 F5C1 497E CDCF FC4B ABA3 2A1A FAEC On Wed, 6 May 2020 at 03:58, Tim Donohue <tim.dono...@lyrasis.org<mailto:tim.dono...@lyrasis.org>> wrote: 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-devel@googlegroups.com<mailto:dspace-devel@googlegroups.com> <dspace-devel@googlegroups.com<mailto:dspace-devel@googlegroups.com>> on behalf of Kim Shepherd <k...@shepherd.nz<mailto:k...@shepherd.nz>> Sent: Monday, May 4, 2020 9:22 PM To: DSpace Developers <dspace-devel@googlegroups.com<mailto:dspace-devel@googlegroups.com>> Subject: [dspace-devel] Re: Unit tests and external (json) resources 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<mailto: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.. Any pointers appreciated! Cheers Kim M: k...@shepherd.nz<mailto:k...@shepherd.nz> T: @kimshepherd W: www.shepherd.nz<http://shepherd.nz> 0CCB D957 0C35 F5C1 497E CDCF FC4B ABA3 2A1A FAEC -- 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+unsubscr...@googlegroups.com<mailto:dspace-devel+unsubscr...@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<https://groups.google.com/d/msgid/dspace-devel/CAKZKfqr%2BRr%3Df8zj%3DxV61u27wJrv1GRv5tkP2sykB5v2Uq4GGpw%40mail.gmail.com?utm_medium=email&utm_source=footer>. -- 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+unsubscr...@googlegroups.com<mailto:dspace-devel+unsubscr...@googlegroups.com>. To view this discussion on the web visit https://groups.google.com/d/msgid/dspace-devel/DM5PR2201MB1148587B9CAD7A63CDAAD122EDA70%40DM5PR2201MB1148.namprd22.prod.outlook.com<https://groups.google.com/d/msgid/dspace-devel/DM5PR2201MB1148587B9CAD7A63CDAAD122EDA70%40DM5PR2201MB1148.namprd22.prod.outlook.com?utm_medium=email&utm_source=footer>. -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/dspace-devel/DM5PR2201MB1148759815996B30FB7F733AEDA40%40DM5PR2201MB1148.namprd22.prod.outlook.com.
