Join GitHub today
Add integration tests #70
I've moved benchmark tests to a separate branch, and made them a separate issue (#72).
When building the containers locally vs. on travis, my table is created with a different ID. This is a similar issue to what's being seen here.
To avoid this we may want to get rid of my python script (this commit fd5a6f0), and instead favor a database dump.
@joshmoore as for where this database dump should live (this repo? As a gist? In nexus? As a docker
I don't think this repo is the best place for it, because hopefully this database will be more general than just imagej-omero test cases. On some level having a docker container is appealing. We could make an omero-test-db, which is based on the postgres docker image. That being said, I'm not certain that's the best move either. Thoughts @ctrueden, @dominikl, @sbesson, @jburel?
What needs to be done before this branch can be merged:
Please let me know if you have any questions or concerns!
This commit modifies the pom to no longer depend on omero-client, but instead use omero-blitz. Additionally, this commit sets the enforcer to be skipped due to a number of duplicate classes.
This removes testng and various logging dependencies, which lead to extraneous logging when building.
By default the integration tests will not run. To run the integration tests use: mvn failsafe:integration-test failsafe:verify -DskipITs=false The verify goal is necessary to ensure that the build fails when all the integration tests do not pass.
The purpose of these tests is to ensure a new ID is assigned to the objects, even though they originated from OMERO. Currently imagej-omero does not update objects on the server, it only uploads new versions.
Thanks @joshmoore! I've updated test.sh to use v0.3.1.
Alright, I believe this PR is ready to merge! Note that this PR adds integration tests for images and tables, and updates the OMERO dependency version to 5.4.
All commits in this PR compile with passing tests (not integration tests).
Ideally we would also push the blitz Maven configuration's version properties and exclusions up to pom-scijava, cut a new pom-scijava, and then update this component to depend on the new pom-scijava version.
I'm willing to wait on all of this until after the PR merges though.