Has anyone set up integration tests for their Confluence Cloud or Jira Cloud app? Details on how you set it up would be much appreciated!
The Server plugin SDK includes native support for integration tests, but we haven’t been able to find any documentation on how to integration test cloud apps.
Specifically, we have a Confluence Cloud app backed by atlassian-connect-spring-boot. We’d like to test it with a real instance of Confluence Cloud in the loop. We were thinking of something along these lines
Create a Confluence Cloud instance prepopulated with integration test data
In CI, start up our app
Generate a random app key, and proxy the the app to the public internet via ngrok
Install the app in the Confluence Cloud instance
Run some REST calls against our app, and verify it correctly fetches and processes data from Confluence.
5: For the REST calls we issue for testing, not sure how to go about authenticating as a Confluence Cloud user interacting with our app (and generating the appropriate jwt)
If anyone has tried and failed that’d be useful to know too
I think the main purpose is to avoid updating the app when descriptor is changed. Luckily, there is an ancient legacy API for UPM that is available, albeit not documented. You can find the logic that Atlassian is using for registering ACE apps automatically in the BitBucket source code
BTW, we run e2e tests using webdriver.io, which in this case sort of work as integration tests (both for internal use, and as part of the requirements for the Cloud Fortified program).
For Confluence, this includes installing the latest version of the app, log in with credentials, go to an empty page, add macro, update macro fields with valid and invalid values and remove the macro.
We are not running them locally (to much hassle) but in CI/CD (staging) and on an hourly schedule for production (for Cloud Fortified certification)
We could leave the app permanently installed, if there’s no absolutely way to programmatically manage addon install/uninstall. The issue with this solution is that we’re limited to running one integration test at a time, so running the tests from CI presents a challenge – they’d stomp on each other.
If each instance of the integration tests generates a unique plugin key, we can have multiple integration tests running simultaneously without affecting each other.
The the multiple-instance approach isn’t feasible, we could set up the tests as a manual trigger against our staging environment (of which there is only one, which eliminates the concurrency issue).
