[KEP 0004] Add Testing Infrastructure #126
Conversation
|
|
||
|
|
||
|
|
||
| ## Motivation |
There was a problem hiding this comment.
Motivation is the higher level item that contains Goals and Non-Goals as members
|
|
||
| ## Motivation | ||
|
|
||
| ### Goals |
There was a problem hiding this comment.
Additionally, do we want to create a definition of "mergeable" for other stories to set the baseline amount of testing required to merge future features once we pull ourselves out of the hole we've given ourselves? Is "tests must be included for new functionality" enough? Is it "overall code coverage can not go down in new PRs without entire group approval (for hard to test things)"?
There was a problem hiding this comment.
I think it would be good to have a definition/requirement like this. The downside of "code coverage" is now that's something we need to be able to track and compare between commits.
Depending on our CI tool, that could in theory be a warning that says "the code coverage went down" to give reviewers insight.
runyontr
changed the title
* First commit for testing kep * Spelling fixes * Set KEP to implementable
* First commit for testing kep * Spelling fixes * Set KEP to implementable
| authors: | ||
| - "@runyontr" | ||
| owners: | ||
| - @runyontr |
There was a problem hiding this comment.
s/@runyontr/"@runyontr"
needs name in double quotes
| ## Summary | ||
|
|
||
| As the complexity and scope of KUDO grows, it becomes impossible to manually validate | ||
| exisiting frameworks and capabilities still function as expected. As part of a robust |
|
|
||
| * Ensure validation of API objects is functioning correctly | ||
| * Ensure controllers execute known process flows correctly | ||
| * Validate Framework and FrameworkVersions in kudobuilder/frameworks adhere to the API spec defined by Kudo. Provide common |
| misconfigurations and validate the testing framework notifies the users/developer of failure | ||
| * Reduce review time for code changes by not requiring reviewers to validate functionality of test cases | ||
| * Reduce developer time for code changes by providing tools to validate functionality | ||
| * Provide developers clear tooling for addition additional tests to infrastructure to validate bug fixes and new features |
No description provided.