-
Notifications
You must be signed in to change notification settings - Fork 4.4k
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
internal/testutils: add a new test type that implements resolver.ClientConn #6668
Conversation
Codecov Report
Additional details and impacted files |
internal/testutils/resolver.go
Outdated
func NewResolverClientConn(t *testing.T, updateState func(resolver.State) error, reportError func(error)) *ResolverClientConn { | ||
return &ResolverClientConn{ | ||
logger: t, | ||
updateStateF: updateState, | ||
reportErrorF: reportError, | ||
} | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we just delete this constructor and export the fields? I think it would be a little more ergonomic since the fields would be initialized by name instead of position in the parameter list.
E.g.
rcc := &testutils.ResolverClientConn{
T: t,
UpdateStateF: func(...) {},
ReportErrorF: func(...) {},
}
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was initially hesitant to do that because I didn't want to store a testing.T
in this type. Ended up exporting the logger
interface.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done.
// ResolverClientConn is a fake implemetation of the resolver.ClientConn | ||
// interface to be used in tests. | ||
type ResolverClientConn struct { | ||
resolver.ClientConn // Embedding the interface to avoid implementing deprecated methods. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we add something to remind ourselves to remove this in the future?
var _ = ResolverClientConn{}.SomeDeprecatedThing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm ... I don't understand this comment.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Writing something like var _ = ResolverClientConn{}.NewAddress
results in an init time panic since this method is not implemented in ResolverClientConn
. I initially made a commit which had this and failed to realize that it was causing a panic. So, I had to undo this in the latest commit.
target: ":80", | ||
}, | ||
{ | ||
name: "", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Add a name?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I honestly don't know what this case is testing. Do you?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done.
tbl: map[string][]string{ | ||
"foo.bar.com": {"1.2.3.4", "5.6.7.8"}, | ||
"ipv4.single.fake": {"1.2.3.4"}, | ||
"srv.ipv4.single.fake": {"2.4.6.8"}, | ||
"srv.ipv4.multi.fake": {}, | ||
"srv.ipv6.single.fake": {}, | ||
"srv.ipv6.multi.fake": {}, | ||
"ipv4.multi.fake": {"1.2.3.4", "5.6.7.8", "9.10.11.12"}, | ||
"ipv6.single.fake": {"2607:f8b0:400a:801::1001"}, | ||
"ipv6.multi.fake": {"2607:f8b0:400a:801::1001", "2607:f8b0:400a:801::1002", "2607:f8b0:400a:801::1003"}, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, I was hoping this and the below table would go away in any rewrite. Is there any way to make this declared in a constructor instead? If it's too much work we can punt, but IMO splitting test code that depends on each other into very distant places is a very bad practice.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I will look into this. But if we can do that as part of a follow up PR, that would be good, since many of the other xDS PRs are gated on the change to add testutils.ResolverClientConn
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Improved the host lookup and srv lookup parts. Working on improving the txt lookup.
// resolver functionality, with scfs as the input and scs used for validation of | ||
// the output. For scfs[3], it corresponds to empty service config, since there | ||
// isn't a matched choice. | ||
var scfs = []string{ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Similar - these are very magical and nowhere near the code that relies on them.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same here. Thanks.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Approved for the current set of changes modulo:
- Delete test case named
""
- Add
var _
business so we know when to un-embed
Done.
Couldn't add this. The comment thread around this has more details. |
Summary of changes:
internal/testutils
:ResolverClientConn
type that implements theresolver.ClientConn
interfacetestutils.TestClientConn
totestutils.BalancerClientConn
and update all references from existing testsinternal/resolver/dns
:internal/resolver/dns/internal
package to house functionality shared between thedns
package and its testsnet.Resolver
interface used from tests into a separate file. This can do with some cleanup to make it more readable and understandable.dns_test
packaget.Run
wherever possiblegrpctest.Tester
and get rid of direct calls to theleakchecker
TestMain
In a follow-up PR, I will using the
testutils.ResolverClientConn
type from the xDS resolver tests.#resource-agnostic-xdsclient-api
RELEASE NOTES: none