-
Notifications
You must be signed in to change notification settings - Fork 257
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
feat: add advancedOptions to streams #722
Merged
Merged
Changes from 1 commit
Commits
Show all changes
5 commits
Select commit
Hold shift + click to select a range
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.
This test doesn't check that, the
advancedOptions
parameter is passed correctly. Check this mock and these tests.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.
Yeah that is correct. But I'm not sure if this is the correct approach.
This will not test any logic in the code. It adds extra logic in the mock, and we test that that logic works.
With mocking apis like this we can only properly test:
There is no good way for us with these tests to test that certain inputs will return certain outputs.
If we want to test that, then we need to look into other testing methods, where we call the actual API. which is something worth doing
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 think my current implementation is too complex and the main idea is not obvious. So I've deleted all conditions for these tests and now it should be more clear. Check this pull request.
IMO this claim is incorrect. Because the main idea of integration tests is that, we want to check if a specific input (or some sequence) returns a specific output. Especially for stateless REST services.
So, we should test scenarios/cases. And of course we can test many scenarios. Basically, we should have the same number of jest tests as we have dedicated mocks in the mock server.
This is common practice. And I can achieve it not only by a code. For example, I've created 3 test mocks for the
getTokenPrice
endpoint using the Postman. I can use the Postman mock server to create 3 integration tests.Check these URLS:
This approach is compatible with the "Red, Green, Refactor". Because when you get a bug, at the beginning you should write a "red" test. After this you should fix your code and make the test green. This is exactly that what I've done in this pull request.
After all, I think the main reason why we need tests/integration tests is that, we want to have a proof that the code works properly. And my remarks refer to that, I don't see the proof that, the
advancedOptions
parameter is passed to the backend service.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.
Ok I see now what you mean. Yeah, this way we can check if the params are correctly provided via check on the server. We should keep the logic minimal though. I like the idea of 'scenarios' the most. I did a similar approach with some other tests.
What I mean by this is that we cannot/should not perfectly simulate server behavior.
We can generalize it to specific scenarios like:
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.
Yes, exactly. Maybe there is some package to handle it nicely. But for now the
lodash
approach is fine too.