Run Integration Tests on GitHub Actions #55
Conversation
Closes: eclipse-kuksa#41 Signed-off-by: Andre Weber <andre.weber3@etas.com>
|
|
||
| val dataEntry = capturingSlot.captured | ||
| val capturedDatapoint = dataEntry.value | ||
| val float = capturedDatapoint.float | ||
|
|
||
| assertEquals(newValue, float, 0.0001f) | ||
| } | ||
|
|
||
| `when`("The same value is set again") { |
There was a problem hiding this comment.
From what I remember this was a system test, when executing "feed Vehicle.Speed 100" twice, the observer was only triggered once. But for some reason this behavior suddenly changed? Funnily this test still ran through successfully on friday.
Since it's no longer relevant I removed the test
|
I ran the build server a few times here to check for "sporadically failing tests": https://github.com/boschglobal/kuksa-android-sdk/actions/runs/7083450303 |
| @@ -123,9 +121,10 @@ class DataBrokerSubscriberTest : BehaviorSpec({ | |||
|
|
|||
| and("When the FIELD_VALUE of Vehicle.Speed is updated") { | |||
| databrokerTransporter.updateRandomFloatValue(vssPath) | |||
| delay(100) | |||
There was a problem hiding this comment.
since exactly = 0 is always fullfilled, the timeout does not apply here.
We therefore have to apply the delay because a) so that the verification is correctly "checked" after the asynchronously behavior would have run through and b) if we don't delay here the next test case in line 145ff is influenced,... (it fails because it receives three onPropertyChanged callbacks... => 1 from subscription, one from the update here and one from the update in the next testcase)
A bit unhappy with all the special edge cases we have for testing the DataBroker#subscribe functionality :(
kuksa-sdk/src/test/kotlin/org/eclipse/kuksa/subscription/DataBrokerSubscriberTest.kt
Show resolved
Hide resolved
kuksa-sdk/src/test/kotlin/org/eclipse/kuksa/subscription/DataBrokerSubscriberTest.kt
Show resolved
Hide resolved
kuksa-sdk/src/test/kotlin/org/eclipse/kuksa/subscription/DataBrokerSubscriberTest.kt
Show resolved
Hide resolved
kuksa-sdk/src/test/kotlin/org/eclipse/kuksa/subscription/DataBrokerSubscriberTest.kt
Show resolved
Hide resolved
kuksa-sdk/src/test/kotlin/org/eclipse/kuksa/subscription/DataBrokerSubscriberTest.kt
Show resolved
Hide resolved
|
@SebastianSchildt |
| @@ -11,6 +11,9 @@ jobs: | |||
| - name: Checkout code | |||
| uses: actions/checkout@v3 | |||
|
|
|||
| - name: "Run Docker Container of Databroker in detached mode" | |||
| run: docker run --pull=always --rm --publish 55556:55556/tcp --detach --name databroker ghcr.io/eclipse/kuksa.val/databroker:master --port 55556 --insecure | |||
|
|
|||
There was a problem hiding this comment.
I think this is fine for this PR, but in the long run,
shall we test again "latest" (i.e. latest "release") or "Master" (bleeding edge) or fixed versions, or a combination thereof? wdyt @wba2hi @lukasmittag ?
There was a problem hiding this comment.
The best behavior would probably be to test against the "latest released version", so that we have a consistent behavior for us and "3rd parties" using our sdk and the corresponding databroker.
Edit: eclipse/kuksa.val#688 this already part of the latest release? Otherwise we get issues with #61 :D
There was a problem hiding this comment.
I think we should opt either for just master or a combination of master and latest. Because I think most of our documentation uses master and so we should test against it. For the future maybe we should change the documentation there too and then only test against latest (once we have a stable release process and release cycle time).
Closes: #41