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

writeToSequential: improve tests for write errors #499

Merged
merged 3 commits into from
Mar 3, 2022

Conversation

drakkan
Copy link
Collaborator

@drakkan drakkan commented Mar 3, 2022

I tryed to improve test cases for write errors as requested in #494

Of course I kept the author for the original commits

Copy link
Collaborator

@puellanivis puellanivis left a comment

Choose a reason for hiding this comment

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

If we rebreak the code, will the test actually fail? I cloned the code locally, and checked, and it seems like it does not.

Monkeying around with things, I think we need to use MaxPacketChecked(3), seed text of "12345", change the check for len(b) == 2 to len(b) > 3, and the test is written != 4.

Reasons:

  • With seed text "hello world" we are not reaching EOF of the input before the read error
  • With seed text "1234" and MaxPacketChecked(2) the original code does not fail
  • With seed text "12345" and MaxPacketChecked(3) the second call is made with len(b) == 2 not len(b) == 3; so we need len(b) > 3.
  • With the new MaxPacketChecked(3) we now do one 3-byte write, and one 1-byte write. This also allows us to distinguish from bad-behavior full-write 3+2, from good-behavior 3+1.

🙃 This corner case is actually pretty hard to reproduce intentionally with minimal code.

client_integration_test.go Outdated Show resolved Hide resolved
client_integration_test.go Outdated Show resolved Hide resolved
client_integration_test.go Outdated Show resolved Hide resolved
client_integration_test.go Outdated Show resolved Hide resolved
@drakkan
Copy link
Collaborator Author

drakkan commented Mar 3, 2022

If now you set the seed text to 1234 the test will not fail since the second write will always return an error

Copy link
Collaborator

@puellanivis puellanivis left a comment

Choose a reason for hiding this comment

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

these are just nitpicks.

expected int
written int
writtenReturn int
writeCounter int
Copy link
Collaborator

Choose a reason for hiding this comment

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

[nit] we don’t really need the write of the writeCounter. This is a writer after all.

if written != 4 {
t.Errorf("sftpFile.Write() = %d, but expected 4", written)
}
assert.Equal(t, 2, w.writeCounter)
Copy link
Collaborator

Choose a reason for hiding this comment

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

[nit] This test is relying on the default typing of untyped integers assigned to interface{} to be int, and thus not as stable as it could be.

Copy link
Collaborator

@puellanivis puellanivis left a comment

Choose a reason for hiding this comment

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

Go ahead and merge as you will with or without addressing the nits.

@drakkan
Copy link
Collaborator Author

drakkan commented Mar 3, 2022

Go ahead and merge as you will with or without addressing the nits.

If you have other comments I will be glad to fix the code, as always thanks!

w.counter++
if w.counter == 1 {
if len(b) != 3 {
return 0, errors.New("this writer require maxPacket = 3, please set MaxPacketChecked(3)")
Copy link
Collaborator

Choose a reason for hiding this comment

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

[typo] “requires”

Copy link
Collaborator

@puellanivis puellanivis left a comment

Choose a reason for hiding this comment

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

You have exhausted all my criticism.

@drakkan drakkan merged commit dcfc1d5 into pkg:master Mar 3, 2022
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.

3 participants