Testing is always an interesting one.
I’d say unit tests for the API functions and unit tests for the controller functions. You could mock the API for the latter. For integration tests, you could use selenium to test the integration between the two. Alternatively, manual integration tests. Personally, I’m hugely in favour of using the API for all business logic for OPAC functionality. The Koha OPAC could be a reference implementation and out-of-the-box solution, but then third party apps and library websites could opt out of using the Koha OPAC and instead just integrate with the API directly. I think a lot of my clients would actually prefer to integrate a Koha OPAC API into their own websites rather than using the Koha OPAC website. I suppose one downside could be the Koha OPAC website could become neglected, if everyone was just maintaining their own user interfaces. But I imagine a lot of people would still want to use the Koha OPAC website too. (After all, integrating with third-party APIs can be very challenging too!) David Cook Systems Librarian Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 Australia Office: 02 9212 0899 Direct: 02 8005 0595 From: Arthur Suzuki <arthur.suz...@biblibre.com> Sent: Tuesday, 8 October 2019 11:17 AM To: koha-devel@lists.koha-community.org; dc...@prosentient.com.au; 'Katrin Fischer' <katrin.fischer...@web.de> Subject: Re: [Koha-devel] API use in intranet and OPAC One but not least issue with JavaScript, how do we test this? I mean it's easy to test the API itself, making requests to it and monitoring the change in the koha db or mock objects. It's also easy to check if the Intranet or Opac page returned by the server contains some strings in the html code (I guess, didn't try though). How do we execute the Javascript in the test and verify it has the expected behavior? Overall I have to say I'm very happy with this change (using more API) though, since it will raise interest for this further and can bring Koha to a whole new level within libraries app, Koha being at the core of other third parties apps to interact with (not to mention them: Coral ERMS and Bokeh Library Frontend). \o/ Le 8 octobre 2019 01:53:59 GMT+02:00, dc...@prosentient.com.au <mailto:dc...@prosentient.com.au> a écrit : I agree with Katrin. I think we need to be careful to think as developers in the open source GLAM space rather than the less accountable corporate space. While I’m a few years out of date when it comes to accessibility, I do still have some friends who are experts in that area and could get their opinion on the matter. From what I remember, Javascript != accessible. I think it was because screenreaders, at least historically, didn’t render the Javascript and that caused the lack of functionality for people with accessibility needs. I’d also add that we can use the API without using Javascript. We could build a lightweight controller which does the API call on the server backend rather than from the client browser, so the user could POST to a CGI .pl script (or a PSGI route), and the API handles all the real business logic. If we wanted to be modern, we could use Javascript to call the API, but fail gracefully by POSTing the form instead if Javascript turns off. I know that would be a lot more work, but that could way we could keep the modernity while also maintaining accessibility. Just my 2 cents. David Cook Systems Librarian Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 Australia Office: 02 9212 0899 Direct: 02 8005 0595 From: Koha-devel <koha-devel-boun...@lists.koha-community.org <mailto:koha-devel-boun...@lists.koha-community.org> > On Behalf Of Katrin Fischer Sent: Tuesday, 8 October 2019 7:31 AM To: koha-devel@lists.koha-community.org <mailto:koha-devel@lists.koha-community.org> Subject: Re: [Koha-devel] API use in intranet and OPAC If we decide to require JavaScript for the OPAC we should be careful to do it in a way that is accessible. Accessibility can even be a legal requirement in some countries for websites of public institutions like libraries. Katrin On 07.10.19 13:28, Kyle Hall wrote: I think it's pretty practical at this point in time to agree that if we are to continue making a modern web app, we need to require javascript. --- http://www.kylehall.info ByWater Solutions ( http://bywatersolutions.com ) Meadville Public Library ( http://www.meadvillelibrary.org ) Crawford County Federated Library System ( http://www.ccfls.org ) On Mon, Oct 7, 2019 at 7:16 AM Marcel de Rooy <m.de.r...@rijksmuseum.nl <mailto:m.de.r...@rijksmuseum.nl> > wrote: Yeah I guess we reached the point that we just need javascript in OPAC ? <http://www.rijksmuseum.nl/> Museumstraat 1 Postbus 74888 1070 DN Amsterdam <http://www.rijksmuseum.nl/> Rijksmuseum.nl Nu te zien: <https://www.rijksmuseum.nl/nl/louise-bourgeois-in-de-rijksmuseumtuinen> Louise Bourgeois in de Rijksmuseumtuinen <https://www.rijksmuseum.nl/nl/nachtwacht> Operatie Nachtwacht Verwacht: <https://www.rijksmuseum.nl/nl/nu-in-het-museum/tentoonstellingen-verwacht> Rembrandt-Velázquez. Nederlandse & Spaanse meesters T/m 18 jaar gratis Please think before you print _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org <mailto:Koha-devel@lists.koha-community.org> https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/ _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org <mailto:Koha-devel@lists.koha-community.org> https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/ Arthur Suzuki Développeur Support chez BibLibre +33 6 37 94 13 53
signature.asc
Description: PGP signature
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
