You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
A majority of the tests in /pkg/cri are testing/validating multiple things per test (generally spec or options validations). This flow lends itself well to using *testing.T's Run method to run each thing as a subtest so go test output can actually display which subtest failed/passed.
Some of the tests in the packages in pkg/cri already did this, but a bunch simply logged what testcase was currently running without invoking t.Run().
Thanks to @samuelkarp for suggesting this on another PR #6996 (comment). I'm not married to the "TestCase" prefix for the subtest names, but it was already used for the log and a couple other t.Run() uses so mostly following how things already were.
I'd probably drop the "TestCase " prefix; I don't think it adds much value. (There could be people parsing the existing t.Log-based output, but...that seems reasonably unlikely as test output and test names can change as we develop them; they're not an interface or a contract.)
I'd probably drop the "TestCase " prefix; I don't think it adds much value. (There could be people parsing the existing t.Log-based output, but...that seems reasonably unlikely as test output and test names can change as we develop them; they're not an interface or a contract.)
A majority of the tests in /pkg/cri are testing/validating multiple
things per test (generally spec or options validations). This flow
lends itself well to using *testing.T's Run method to run each thing
as a subtest so `go test` output can actually display which subtest
failed/passed.
Some of the tests in the packages in pkg/cri already did this, but
a bunch simply logged what sub-testcase was currently running without
invoking t.Run.
Signed-off-by: Daniel Canter <dcanter@microsoft.com>
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
A majority of the tests in /pkg/cri are testing/validating multiple things per test (generally spec or options validations). This flow lends itself well to using *testing.T's Run method to run each thing as a subtest so
go test
output can actually display which subtest failed/passed.Some of the tests in the packages in pkg/cri already did this, but a bunch simply logged what testcase was currently running without invoking
t.Run()
.Thanks to @samuelkarp for suggesting this on another PR #6996 (comment). I'm not married to the "TestCase" prefix for the subtest names, but it was already used for the log and a couple other
t.Run()
uses so mostly following how things already were.