Anxiously looking forward to it.
I think that the one within your scope is this: GitHub - openmrs/openmrs-ocl-client: OCL Client for OpenMRS
If you just wanna see what the other OCL projects are, you can look at them via this: Open Concept Lab: Project summary - OpenMRS Bamboo
There’s only one OCL for OpenMRS client code base. There are two different versions of the backend (OCL API), but that’s the responsibility of the OCL dev team (provided that the client works against both versions).
FYI, in OCL for OpenMRS, we are currently running running the Cypress tests as part of every Travis build.
Hi @k.joseph - any updates on this work? After talking with @dkayiwa today, it sounds like we seriously need to have a Bamboo CI plan that runs our existing platform unit tests on both MySQL and PostgreSQL.
It also sounds more urgent than the Gherkin and Selenium/Cypress tests work at the moment, since a test can pass on MySQL but fail on PostgreSQL. (e.g When a developer uses a MySQL specific SQL syntax instead of the standard one which runs on both MySQL and PostgreSQL) (kudos goes to @dkayiwa for explaining this to me).
@k.joseph what do you think?
Here is an example of what would not have happened if we had these tests.
Since the release of platform 2.2.0 up to now, the platform upgrade wizard screens have been broken. It took me a while to figure it out, only to discover that it all came from this ticket GCI-199. A number of variables were reported as unused by Sonar and hence got removed as part of our GCI program with that ticket: GCI-199. It turned out that though these variables were not used anywhere in the Java source files, they were actually used in the velocity templates of the database update wizard screens. Even more interesting is the fact that am the one who reviewed and merged the pull request. 
To cut the long story short, if we had automated tests for this, we would have noticed this immediately, instead of releasing 3 major platform versions (2.2, 2.3, 2.4) with broken upgrade wizard screens.
FWIW, this is of higher priority than the ongoing reference application ui tests. I fixed the bug yesterday, but the tests do not yet exist. Just in case it happens again without anyone being aware.
@dkayiwa ,
Coming back to this ,
Of recent i was starting on writing Integration Tests for the Service layer in OpenELIS , and i used TestContainers a Java library that provides and manages lightweight docker instances of common databases.
We can run the Integration tests against real databases like MySQL and Postgres managed by TestContainers.
Here is sample , running the tests on Postgres
And i think its not very hard to setup this.
As long as we start the test-database instance using TestContainer in the test enviroment , we just need to do some refactoring here ,and add more other test-database configurations like what i set here , and then be able to switch between the different test-databases
Do you have some time for a rough proposal of how such a pull request could look like?
We curently use the useInMemoryDatabase Sytem Property to switch between a real Database and an In memory database ,though I cant see where useInMemoryDatabase is actually set, but we can still use a SytemProperty to switch between the different test Database containers for MysQL and Postgress .
I think we can set a System Property ie testDatabase = mysql/postgress , we then add more configurations here for Both MySQL and PostgreSQL , and TestContainers will start the given databse instance depending on the value of System Property above ie testDatabase
With this approach , one can even mount an sql dump file that loads demo data into the database container, at startup . Something like here
Yes @mozzy we can run integration tests on MySQL database. You simply query a given db name.i like the idea of using TestContainers
Hello @dkayiwa , i was just thinking of an easy approach we can use to switch between the different test databases , does using a System Property makes sense ??
because its easy to set this with maven
mvn test -DtestDatabase=mysql
or
mvn test -DtestDatabase=postgress