Traditionally, with the LegacyUI, beta-testing involved manually testing different features of the UI. Since Platform 2.0 is based on a REST-ful architecture and it is exposed only via the bundled REST-WS module and FHIR modules, we should aim to automate the process of testing the rest endpoints instead of doing that manually during the beta-testing phase.
A cool tool I found online is http://frisbyjs.com/ . But it will require a lot of work for the initial set-up. i.e manually configuring all the endpoints and providing expected response objects.
I was wondering if the developer community has any suggestions or recommendations on how to go about testing the rest-endpoints of Platform 2.0.0-beta during the beta testing phase. 
I’m a little bit out of my league here, but weren’t we using rest-assured at one point? Would it work for what you need?
How about something like swagger-test-templates - or some other way to generate an initial set of tests automatically using our OpenAPI spec?
As an aside, could we configure CORS on our demo site so people can test their frontend apps in the browser against it?
1 Like
I don’t understand, there are hundreds of unit tests in the REST WS module (about 1300 if my IDE is right). It’s irrelevant if they are written in Java (any language can be used), I don’t see the point of rewriting them in JS if this is what you mean. Please clarify.
2 Likes
We should write them in a language which isn’t verbose 
We’re testing a RESTful API – why do you we need to write it in Java? Everything is done via HTTP…soo…
@lluismf is right, the REST API is already largely tested, and there is no need to replicate all of this, or to rewrite it in a new framework.
We should add a small number of smoke/integration tests that exercise the platform’s REST API on a couple of end-to-end scenarios, and these should be run against an actually-running platform in jetty/tomcat.
But we only need a few, not a massive number.
-Darius (by phone)
1 Like
To demonstrate your point, take one of the existing tests and rewrite it in a non-verbose, RESTful/HTTP appropriate language (whatever that means). Easy.
nevermind – forget I said it 
Should we just get some scenarios listed, then use the existing framework to write the tests? Its just a single test with more than one webservice call, right?
2 Likes
I would like share with you my experiences on this matter.
I have just taken my first stab at implementing an OpenMRS REST api (for Metadata Mapping Module) and I have to say the related unit testing documentation, helper classes and existing unit test have been very difficult to get a grip of. Well, documentation is always lacking but I find the approach to REST implementation unit testing just fundamentally very confusing. Let me elaborate.
Unit tests based on DelegatingCrudResourceTest or MainResourceControllerTest are more about testing implementation details of say, a REST resource based on MetadataDelegatingCrudResource, and thus it is very difficult to see if and how they actually verify the contract of the REST api. Another layer of obfuscation comes from testing different versions of an api with unit test classes that extend one another.
How-to documentation can of course be improved (even I have a TODO on my personal list to improve said documentation) which makes writing these tests easier but reading tests might still be cumbersome. I also see value in tests as documentation. Meaning: you look at a test and understand how the api that is tested works. Mainly the target group for tests-as-documentation is developers (and maybe testers) as no one else looks at these tests but this is an important target group.
Having REST api tests that are more like integration tests and somehow correspond to the structure of the api would help a lot. I have to admit I do not have experience in writing this kind of tests but I’d still think they would be worth doing if we figured out a neat and easy-to-read way of writing the tests.
In summary: current approach to REST testing is very confusing for newcomers and does not work as documentation. Might work ok for experienced developers and, in the end, even verify api contracts.
1 Like
I agree 100%, but I think it’s the own nature of the REST module (that must run on multiple versions of CORE) that leads to the tests having to cover multiple versions of the API. The class hierarchy of REST resources (very complex) leads naturally also to the hierachy in the test classes.
I don’t know details of how OpenMRS’s current REST testing framework looks like. But, I would also recommend using rest-assured if you are thinking of trying out something different. We used rest-assured on MifosX for writing integration tests around most commonly used scenarios, and we found them very easy to write / maintain / wrap in user-understandable domain objects. Here is a link to the tests if anyone is interested: Loan Integration Test
2 Likes