Skip to content

Conversation

@pgillich
Copy link

@pgillich pgillich commented Jun 4, 2023

These unit tests are faking network responses from docker repository. So coverage is increased without a real docker repository on the network.

Signed-off-by: pgillich <pgillich@gmail.com>
Copy link
Collaborator

@mtrmac mtrmac left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks!

Just to be explicit, most of c/image is currently integration tested via https://github.com/containers/skopeo/tree/main/integration , which is a mandatory part of c/image CI. Are you seeing some real failures, or insufficient coverage there? (It’s quite possible that’s the case.)

Or is there some other specific thing you want to achieve with these tests?

That said, having fast unit tests that trigger failures immediately during development would certainly be useful; it’s just that with the Skopeo tests existing, we couldn’t find the time to do that.


Conceptually, I think unit test for the transports like docker://, and for the core copy logic in c/image/copy, are independent; a single test for a dockerdocker-archive copy, exercising three separate packages, is really more of an integration test, and doing that at the top level with a Skopeo command seems good enough (given how thin a layer Skopeo itself is over c/image/copy).


Managing the fake HTTP responses manually seems to me to be a fairly large hassle, both to potentially extend, and to maintain, e.g. when the real-world responses change or we need to handle more kinds of them.

Compare old #254 for an alternative — record real-word interactions as files, not as Go code, and if something changes, just re-record them.


// RegisterTestClientRoundTripper registers testClientRoundTripper, if set.
// Calls Transport.RegisterProtocol.
func (sys *SystemContext) RegisterTestClientRoundTripper(transport *http.Transport, schemes []string) *http.Transport {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don’t think the internal unit test implementation should leak to the external API like this.

Instead, unit tests (assuming they don’t span multiple packages) can call the private newImageSource/newImageDestination with an internal-only extra parameter.

Default: []signature.PolicyRequirement{
signature.NewPRInsecureAcceptAnything(),
},
Transports: map[string]signature.PolicyTransportScopes{
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

With Default set, it should be possible to leave this empty.

@pgillich
Copy link
Author

I accept @mtrmac comments, his proposed way to make automatic tests is better and I close this PR.

@pgillich pgillich closed this Aug 10, 2023
@pgillich pgillich deleted the simple_docker_fake_unit_tests branch August 10, 2023 18:21
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants