Replies: 1 comment
-
|
Hi @erickguan, thank you so much for your work on this! Your efforts in improving this part are truly appreciated! I will do my best to provide some context about our testing infrastructure. OpenDAL features a behavior test that all services must pass, which can be found here: https://github.com/apache/opendal/tree/main/core/tests/behavior. Each commit triggers these behavior tests via GitHub Actions, as shown here: https://github.com/apache/opendal/actions/workflows/test_behavior.yml. For example, you can view a specific run at: https://github.com/apache/opendal/actions/runs/11427895126. OpenDAL integrates with real storage services for testing, configured through our 1Password infrastructure. If there is an open-source deployment available, we will set up a fixture for it: https://github.com/apache/opendal/tree/main/fixtures. For more information, you might be interested in my blog post about the behavior test: https://xuanwo.io/2024/03-how-to-condense-800-integration-tests-into-80-losslessly/. |
Beta Was this translation helpful? Give feedback.
-
When I worked on improving core services, I found that tests are quite limited. I would have more confidence and have a simple understanding about usages with tests.
As a start, I would not write about architecture of opendal but start with the tests when making improvements. When contributes to various of core services, I would want to have and trigger tests, at least for a few important services.
I consider adding these tests:
The tricky thing is that opendal supports many cloud services. Running tests will be expensive or difficult to configure/mock. Besides that, we can also argue if we should add tests at this stage since it will be more difficult to change them.
Let's say, taking fs, memory, postgresql, s3, webdav services, where can developers add these tests? What would be an acceptable test improvements?
As a context, opendal is at the version 0.50.0 currently.
Beta Was this translation helpful? Give feedback.
All reactions