-
Notifications
You must be signed in to change notification settings - Fork 4.9k
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
CA trusted fingerprint tests #29347
CA trusted fingerprint tests #29347
Conversation
This pull request does not have a backport label. Could you fix it @belimawr? 🙏
NOTE: |
Pinging @elastic/elastic-agent-data-plane (Team:Elastic-Agent-Data-Plane) |
@@ -49,15 +47,15 @@ func TestMakeVerifyServerConnection(t *testing.T) { | |||
peerCerts []*x509.Certificate | |||
serverName string | |||
expectedCallback bool | |||
expectedError error | |||
expectedError bool |
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.
Why did you change this?
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.
The validation using this field as an error wasn't quite correct, it used be like this:
assert.Error(t, test.expectedError, err)
However assert.Error
's signature is: (t TestingT, err error, msgAndArgs ...interface{}) bool
, hence the test was validating that the test case had an error set and using the returned error as a message.
I did try for a wee bit to get one of the other error functions provided by testify to assert the error type, but they didn't quite work, nor I invested much time on it. In the end it was simpler and quicker to just test for error/no error.
Does it make sense? Do we need to be more specific while checking those errors?
Testify can be quite hard to use...
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've improved the tests to also validate the error type and message on bc05440788.
💚 Build Succeeded
Expand to view the summary
Build stats
Test stats 🧪
💚 Flaky test reportTests succeeded. 🤖 GitHub commentsTo re-run your PR in the CI, just comment with:
|
This commit adds tests to `trustRootCA` and `makeVerifyConnection`, the tests aim to cover the usage of `ssl.ca_tursted_fingerprint`.
* `openTestCerts` receives a `testing.TB` and fail tests in case of an error * fixing testify usage
42c1a0f
to
bc05440
Compare
rebase onto master, force push |
bc05440
to
5c7ebfb
Compare
/test |
2 similar comments
/test |
/test |
/test |
This commit adds tests to `trustRootCA` and `makeVerifyConnection`, the tests aim to cover the usage of `ssl.ca_tursted_fingerprint`. Some existing tests were refactored, `openTestCerts` receives a `testing.TB` and fail tests in case of an error (cherry picked from commit 6c268f8)
This commit adds tests to `trustRootCA` and `makeVerifyConnection`, the tests aim to cover the usage of `ssl.ca_tursted_fingerprint`. Some existing tests were refactored, `openTestCerts` receives a `testing.TB` and fail tests in case of an error (cherry picked from commit 6c268f8) Co-authored-by: Tiago Queiroz <[email protected]>
What does this PR do?
This PR adds tests for when
ssl.ca_trusted_fingerprint
is setWhy is it important?
It increases our test coverage and ensures the implementation is correct.
Checklist
- [ ] I have made corresponding changes to the documentation- [ ] I have made corresponding change to the default configuration files- [ ] I have added an entry inCHANGELOG.next.asciidoc
orCHANGELOG-developer.next.asciidoc
.Author's Checklist
How to test this PR locally
libbeat/common/transport/tlscommon
go test ./...
Related issues
Use cases
Screenshots
Logs