Open sophokles73 opened 8 months ago
Sounds good to me, if we can get same (or better) coverage. Maybe @argerus some opinion on this, as I do think the existing integration tests were done by you?
I'm all for migrating them (and no, I didn't write them).
Ah, that was @lukasmittag :) WHo meanwhile also tinkered with Cucumber. @lukasmittag would you agree we can get rid of the python based integration tests and achieve the same with cucumber?
They are mostly testing the sdv.databroker.v1 interface. Cucumber and Gherkin is testing the kuksa.val.v1 interface. So I am leaning on keeping them for now. But it is possible to port them yeah (at a later time maybe). So let's keep this open.
Is the sdv.databroker.v1
API still supported? My understanding was, that Databroker's API is kuksa.val.v1
...
It is "still supported", especially as some user such as Velocitas are usually a lot of versions behind, but we are not modifying it and are putting new improvements/features only in the kuksa.val API. Thus, I would not add support for sdv API in Cucumber tests. However, if the "old" tests are testing the sdv interface, it might be worth to have still around as long as we do have the interface shipped
Fair enough. Have you already deprecated the sdv.databroker.v1
API? If not, I predict that Velocitas will use it forever ;-)
The integration tests in the
kuksa_databroker/integration_test
seem to provide only very limited coverage. Given that there also is a Cucumber based (integration) test suite, I wonder if it would make sense to migrate the few existing tests to Cucumber so that we do not need to maintain both test suites (including all of the boiler plate helper code around it)?