Add backend integration tests and test product entitlement mapping endpoint#979
Conversation
| sharedPreferences = mockk<SharedPreferences>().apply { | ||
| every { getString(any(), any()) } answers { secondArg() as String? } | ||
| every { edit() } returns sharedPreferencesEditor | ||
| } |
There was a problem hiding this comment.
Note how I've had to mock the appConfig and the sharedPreferences. Both of those require a Context which is not available during unit tests.
| include "com/revenuecat/purchases/backend_integration_tests/**" | ||
| } else { | ||
| exclude "com/revenuecat/purchases/backend_integration_tests/**" | ||
| } |
There was a problem hiding this comment.
This makes it so, when we run unit tests normally, we won't be executing these integration tests. Only if we add the RUN_INTEGRATION_TESTS property we will run those tests exclusively.
| class BackendIntegrationTest { | ||
|
|
||
| companion object { | ||
| private val TIMEOUT = 5.seconds |
There was a problem hiding this comment.
Note the timeout here is a bit high... But I got a couple of failures with 2 seconds, not sure if there was a reason for it to be so slow...
| - test | ||
| - detekt | ||
| - assemble-sample-app | ||
| - run-backend-integration-tests |
There was a problem hiding this comment.
I think it should be fine to run these on all commits... They shouldn't take too long.
…t entitlement mapping endpoint test in both
| import org.assertj.core.api.Assertions.assertThat | ||
| import org.junit.Test | ||
|
|
||
| class LoadShedderBackendIntegrationTest: BaseBackendIntegrationTest() { |
There was a problem hiding this comment.
The way I structured this right now, these and production backend integration tests live in the same place and are run at the same time. They are pretty fast though so I think that's fine. Lmk if you would prefer to run them separately.
| paths_of_files_to_update: [constants_path] | ||
| ) | ||
| replace_text_in_files( | ||
| previous_text: 'LOAD_SHEDDER_API_KEY', |
There was a problem hiding this comment.
Should this be LOAD_SHEDDER_REVENUECAT_API_KEY?
There was a problem hiding this comment.
So I used LOAD_SHEDDER_API_KEY in the Constants.kt file to avoid accidentally changing it in the previous replace, where we replace REVENUECAT_API_KEY. We could use patterns to avoid that problem though I guess, but this works for now.
| block(latch) | ||
| latch.await(TIMEOUT.inWholeSeconds, TimeUnit.SECONDS) | ||
| assertThat(latch.count).isEqualTo(0) | ||
| } |
There was a problem hiding this comment.
Yeah, I think this could be useful for many other tests as well. For now I'm just using it here but we could consider it moving to the test-utils module and use it in many other tests.
…dpoint (#988) ### Description SDK-3015 This PR adds backend integration tests. These are setup as unit tests in the `common` module. I thought about adding these as instrumentation tests, but that increases the complexity and runtime of these tests, and we can relatively simply run them as unit tests in the JVM. This is an almost duplicate of #979. Those changes were lost after being merged to the wrong branch. Only change after that is fixing the load shedder test now that we are actually requesting to the load shedder after some backend changes.
Description
SDK-3015
This PR adds backend integration tests. These are setup as unit tests in the
commonmodule.I thought about adding these as instrumentation tests, but that increases the complexity and runtime of these tests, and we can relatively simply run them as unit tests in the JVM.