-
Notifications
You must be signed in to change notification settings - Fork 6
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
Migrate test suite to end-to-end tests #35
Conversation
106b75e
to
e0cfe5d
Compare
…/stopping it for each test method.
We can't throw assertion errors without affecting the server's stability, which means we need to move the expectations outside the stubbing of the fixtures. This commit does all changes necessary and adapts all tests by first setting the server's behavior and then providing means to ask about what's happened. Everything related to the expected request that the API should have done is made through a new object of type RecordedRequest that the server provides. Everything related to the response must be tested through the actual output of the client call, which supports the idea of these tests being end-to-end.
e0cfe5d
to
7104d68
Compare
Did a quick first pass and looks good. Tests run ✅but wonder if we can keep them less verbose. |
Just realized that I had some |
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.
After live-reviewingthis with @ggalmazor, this looks good 👍 ✅.
I raised some questions that can fit in the roadmap Guille is gonna draft. Thanks!!!
Fixes #34
This PR affects only to the tests codebase.
This PR introduces a new
TestHttpServer
class responsible for replaying HTTP fixture files and providing tools to make assertions about the HTTP request that this API client makes.The biggest change this PR introduces is a change in the way we express expectations, by asserting through a
RecordedRequest
object. This is due to the limitations of running the JUnit assertions in the same thread that the server is running, which is not possible without putting an important amount of effort into it. As a consequence, testing has to be made following these general ideas:DNSimpleBaseTest
provides aserver
and aclient
instance and ensures that there's no interference between test methods.RecordedRequest
object thatserver.getRecordedRequest()
provides. This object includes the JSON payload, headers, path, and HTTP method information which allows any of the existing assertions to be made.server.stubFixtureAt(String path)
can be used to configure the server to replay a fixture file as the response to requests.For now, it's a basic stubbing system that will replay the same one fixture for all requests, but it could be easily extended to replay sequences of fixtures for multiple requests or specific fixtures per requested path or HTTP method.
thrownException
matcher that enables verifying the exception class and doing introspective testing as well. Example:DomainDnssecTest.testDisableDnssecWhenNotEnabled