k8s-triage-robot
commented
10 months ago The Kubernetes project currently lacks enough contributors to adequately respond to all issues.
This bot triages un-triaged issues according to the following rules:
- After 90d of inactivity,
lifecycle/staleis applied - After 30d of inactivity since
lifecycle/stalewas applied,lifecycle/rottenis applied - After 30d of inactivity since
lifecycle/rottenwas applied, the issue is closed
You can:
- Mark this issue as fresh with
/remove-lifecycle stale - Close this issue with
/close - Offer to help out with Issue Triage
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale
k8s-ci-robot
/kind feature
Summary
When developers enter the typical development cycle they can experience challenges. This issue outlines some of those challenges with the hope of creating smaller issues to address the concerns.
Development cycle challenges
The use of Ginkgo in unit tests has created hard to follow test logic
When reading the test source developers can find themselves jumping between stacked
BeforeEachstatements to identify mocking expectations that aren't necessarily obvious in individual tests.It would be helpful if unit tests were more self contained (using little or no
BeforeEachstatements spread vertically across the test sources) and/or relied solely on native testing capabilities in the language.The Makefile
testdepends on generation and lintingDepending on generation and linting in the
testrecipe inflates the test cycle. When tests are compiled it will become obvious mocks aren't defined correctly (IDEs may catch the issues earlier). Linting is its own recipe and can be removed fromtest(again IDEs may highlight linting issues early and the CI will catch them). We may want a recipe that still runs runs the various generation and linting recipes, however its important developers can iterate quickly and the existing setup creates a poor experience.These concerns are orthogonal to the CI. The CI should run checks to ensure generated sources are up to date and lint the code.
Running individual tests can be challenging
Go developers are usually accustomed to
go test. However,go testdoesn't work on several of our packages as we've munged integration tests that leverageenvtestwith unit tests. Consequently unit tests, that are ideally invokable with justgo test, can't be run independently. Furthermore, thetestrecipe doesn't offer a filter for running tests in isolation making it difficult to focus in on problem areas.The code structure makes adding new tests challenging
The code architecture bundles significant logic into algorithms, particularly in the
/pkg/cloudpackage. In some instances, this may be appropriate, but in others it seems we've exported methods for better testability (code smell). The code could benefit from some restructuring to make it more testable and transitively easier to work with.