-
-
Notifications
You must be signed in to change notification settings - Fork 959
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Remove one of in-memory/on-disk SQLite e2e runners and replace with faster test #580
Comments
I agree that it currently adds too much time. Essentially I think we need to have test coverage of the setup & initialization phase for both flavors (in-memory & on-disk). For the functional tests afterwards either one should be sufficient (do we have a favorite here?). In the end I think we need to ensure that we catch all the different problems we found on the way to fix #574 in our normal tests. Right now I dont know enough about the test concept of Kratos to sketch out the best setup. In general we should to cover the following specific cases for in-memory:
Having this in place we can remove "memory" flavor from e2e tests again. The e2e flavor SQLite will ensure that everything works on SQLite assuming on-disk and in-memory behave the same. @zepatrik @aeneasr what do you think and any pointer how to do t/ where to add the startup/init test? |
I would prefer having on-disk for e2e as it allows debugging the SQLite database when tests fail!
I think we could either test |
Is your feature request related to a problem? Please describe.
Right now we check if the binary starts up using e2e tests - for example the in-memory e2e tests recently established by #574
Because the implementation of in-memory and on-disk SQLite is minimal, I think we should run just one of the two - especially because the e2e tests need around 10 minutes per task to complete.
Describe the solution you'd like
Remove either the on-disk or in-memory SQLite tests from the e2e suite and find another way to introduce a test that would have caught what #574 fixed.
The text was updated successfully, but these errors were encountered: