Skip to content
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

Make testing service validation easier #5175

Merged
merged 1 commit into from
Mar 12, 2015

Conversation

thockin
Copy link
Member

@thockin thockin commented Mar 9, 2015

Part of multi-port services.

If people like this, we could start to apply this pattern elsewhere.

TL;DR: don't redefine objects over and over changing one thing each
time. Instead provide a func that mutates a base object to test facets
of validation. Much easier to read and to update.

Part of multi-port services.

If people like this, we could start to apply this pattern elsewhere.

TL;DR: don't redefine objects over and over changing one thing each
time.  Instead provide a func that mutates a base object to test facets
of validation.  Much easier to read and to update.
@alex-mohr
Copy link
Contributor

FWIW, I'm kind of ambivalent about these kinds of factorings. I think for pure validation testing having a base valid object and changing it to make it invalid is good -- as done here.

But for most testing, I generally prefer less indirect code in tests and more "this specific configuration is supposed to be valid" as it's sometimes less prone to issues where you're not actually testing what you think you're testing. Don't feel amazingly strongly though. Note there was a ToTT in the last year on this issue, but I can't find it via a quick search -- and happy to defer to @ixdy on this.

@thockin
Copy link
Member Author

thockin commented Mar 12, 2015

In general I agree. In this case I found myself doing REALLY dumb, repetitious changes over and over due to something totally unrelated to the test. In so doing I could not even figure out what the different test cases were actually testing.

Ideally a test case contains JUST the code needed to capture the exact scenario. I think this approach does that much better. Of course, this kind of test is very specific, so this pattern may not apply to other cases.

@bgrant0607
Copy link
Member

We've talked about various solutions, including "test fixtures", such as this -- common patterns could go into testing libraries.

Personally, I think we shouldn't ever be directly creating objects using the internal representation.

But this doesn't seem worse than what existed.

@thockin
Copy link
Member Author

thockin commented Mar 12, 2015

It's a step towards constructors, anyway

On Wed, Mar 11, 2015 at 8:55 PM, Brian Grant notifications@github.com
wrote:

We've talked about various solutions, including "test fixtures", such as
this -- common patterns could go into testing libraries.

Personally, I think we shouldn't ever be directly creating objects using
the internal representation.

But this doesn't seem worse than what existed.


Reply to this email directly or view it on GitHub
#5175 (comment)
.

@bgrant0607
Copy link
Member

LGTM

@bgrant0607 bgrant0607 added the lgtm "Looks good to me", indicates that a PR is ready to be merged. label Mar 12, 2015
nikhiljindal added a commit that referenced this pull request Mar 12, 2015
Make testing service validation easier
@nikhiljindal nikhiljindal merged commit d9249a2 into kubernetes:master Mar 12, 2015
@thockin thockin deleted the plural_services_10 branch March 20, 2015 05:34
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
lgtm "Looks good to me", indicates that a PR is ready to be merged.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants