-
Notifications
You must be signed in to change notification settings - Fork 9.8k
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
Unify testing framework #13637
Comments
We have managed to merged enough PRs to establish fundaments for the new framework (#13708, #13740, #13753, #13754). I think we can open the effort to more contributors to scale the migration. I think it would be a good idea to encourage new tests to be implemented in new framework. I think we can do migration file by file each assigned to single person. I as already started I will continue working on Tests to be migrated:
Note for contributors: Feel free to pick one of the directories and just leave a comment that you want to work on it. |
I will work on follow tests:
|
hi @serathius I would like to take some |
I would start with the simple one: |
will continue with: |
hi @serathius, Because the cli commands like So I think maybe it shouldn't be migrated. What is your suggestion? thanks! |
Thanks for looking into this. Please skip the |
got it, thanks. |
i am working on
|
I can take a few more.
Update... I just realized above 3 test files should not be classified as common tests shared by I am inclined to skip the above tests and leave them as they are. WDYT? @serathius Will continue the following tests tomorrow..
|
Makes sense, those tests cannot don't make sense for integration tests and will require different approach. Let's leave them for now. Thanks for pointing this out. |
anyone working on
|
It got closed because of the PRs that was merged included text |
oops. I will avoid the |
I'm working on:
|
This issue has been automatically marked as stale because it has not had recent activity. It will be closed after 21 days if no further activity occurs. Thank you for your contributions. |
Going to work on e2e/ctl_v3_grpc_test.go |
I'm a new contributor. I will try migrating the test: e2e/discovery_test.go |
New Contributor. Will try to migrate e2e/ctl_v3_lease_test.go |
Test flakiness and maintenance cost remains one of the larger issues for Etcd project. Proposals like #13167 to track flakiness and contributions to address singular tests have definitely helped however to fully resolve the problem we also need to address the root cause. Etcd projects currently maintains multiple disconnected ways to run tests (unit, integration, e2e, functional) that mostly verify the same scenarios. Testing features on different level is itself desired as it allows to isolate failures and speed up resolution, however not in a way that is currently done in Etcd. Almost zero test scenario and test framework is reused. This means that we have multiplied test code lines without any benefit.
Goal:
I propose to unify testing by identifying common test scenarios, test framework operations and making them accessable the same way no matter which test method is used (unit, integration, e2e, functional). For example simple put&get test scenario goes through very same stages no matter if this is integration or e2e cluster: create cluster, execute put, execute get, compare results, cleanup. This test should be written once and executed on different layers, no matter if underneath framework runs a fake grpc client or starts whole process. With this we will reduce number of code lines as each test will be needed to be implemented once, hide all the differences between test types reducing knowledge needed to add new tests and improve deflaking process by comparing same test results from different methods (we can isolate test location, if both e2e and integration tests fail then feature is broken, if only one of them then the test framework)
At this moment I would be most effective to target unifying integration and e2e tests as they are most similar in both cluster setup and test scenarios. We should be able to identify minimal common interface for cluster creation and communication that would allow us to start rewriting tests.
Plan:
Cluster
andClient
interfaces intests/framework
.tests/framework/e2e/cluster.go
andtests/framework/integration/cluster.go
and migrate them one by one.tests/common
that will be invoked by e2e and integration.cc @ptabor @ahrtr @spzala
The text was updated successfully, but these errors were encountered: