Test strategy #114
Labels
No Label
AdminAPI
Bug
Check AWS
CI
Correctness
Critical
Documentation
Ideas
Improvement
Low priority
Newcomer
Performance
S3 Compatibility
Testing
Usability
No Milestone
No Assignees
2 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: Deuxfleurs/garage#114
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Define our test strategy. Testing is a research field on its own.
I think we should aggregate some references to take an informed decision.
About testing distributed systems:
About S3 compatibility:
About benchmarking S3 (I think it is not necessarily very relevant for this iteration):
Engineering blog posts:
Misc:
test-smoke.sh
script as a proper Rust integration test.execve
)garage
as a library, the entrypoint would be a simple call to this library. From the test, we could also import and call this library.My current opinion on this subject:
Feel free to contribute references
My opinion is that we should try to test in least invasive ways, i.e. minimize the impact of the testing framework on Garage's source code. This means for example:
garage
a shared library (launch usingexecve
, it's perfectly fine)Instead, we should focus on building a clean outer interface for the
garage
binary, for example loading configuration using environnement variables instead of the configuration file if that's helpfull for writing the tests.There are two reasons for this:
Reminder: rules of simplicity, concerning changes to Garage's source code. Always question what we are doing. Never do anything just because it looks nice or because we "think" it might be usefull at some later point but without knowing precisely why/when. Only do things that make perfect sense in the context of what we currently know.
Wrt testing strategies, let's make a list of things we want to try. Sort them from the most promising to the less promising. Try them in that order, aborting early if it's too complicated or not giving any good results.
Interesting blog posts on the blog of the Sled database:
I think this review should be put in our documentation and this issue closed.
Agreed, I'll make a PR