-
Notifications
You must be signed in to change notification settings - Fork 588
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
Increase unit test coverage #2910
Comments
/triage accepted |
@sedefsavas: The label(s) In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
This is issue should be covered here: #2569 |
WIP list for the scenarios covered in AWSCluster controller tests :
Integration tests:
|
/assign |
/assign |
/assign |
WIP list for scenarios covered for AWSMachine controller:
|
I will start working on pkd/cloud/services/ssm package |
Adding more cases which can be covered as part of cluster controller tests:
|
@Madhur97 PTAL
This is already covered in the test cases I added
I think 2-10 can be taken care in scope package(session_test.go), wdyt?
Already covered in vpc_test.go
Can be taken care in vpc_test.go if not already covered.
Already covered in subnets_test.go
Already covered in securitygroups_test.go
Can be covered in securitygroups_test.go if not already covered.
Can be covered in bastion_test.go, anyways getting covered in the test case (Should not create VPC in case of unmanaged VPC)
Can be covered in bastion_test.go, anyways getting covered in the test case (Should not create VPC in case of unmanaged VPC)
Can be covered in loadbalancer_test.go
Already covered in loadbalancer_test.go
Can be covered in loadbalancer_test.go
I think all conditions can be checked(except PrincipalCredentialRetrieved, PrincipalUsageAllowedCondition as these are specific to scope) in current test cases only, I will add those checks |
@Madhur97 @Ankitasw Our aim is to make the code base well tested by using webhook tests, integration, unit, and e2e tests wherever suitable. For instance, #3 can be a webhook test, #4, #5, #6, #7 etc could all be tested well with unit tests. |
Also, in integration tests, we can try to merge multiple scenarios into a single test, which saves us time. Also, for testing specific situations, we can use fakeClient too (in scenarios where testing with envtest becomes more complicated). |
Missed scenarios in launchtemplate.go unit tests:
|
I will work on package |
pkg/cloud/services/autoscaling: |
Added all the above scenarios in the updated PR |
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle stale |
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle rotten |
This issue is to track improving our current unit-test coverage which is as follows:
Prow link for the interactive UI above.
Artifacts of the test-coverage prow job are here for more details.
The text was updated successfully, but these errors were encountered: