-
Notifications
You must be signed in to change notification settings - Fork 25
Create integrations tests for all MeiliSearch http routes #54
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
Conversation
|
@curquiza Please review the tests, I am not sure what to do with the failed tests. Please bear that this PR is still a draft. |
d831059 to
f5b7391
Compare
|
Hello @ppamorim! Thanks for this awesome PR! You can now rebase your branch 🙂 |
f5b7391 to
ec7254e
Compare
|
@curquiza Just did this. |
|
awesome @ppamorim. If your PR is ready for review, can you remove the draft status of this PR? 🙂 |
1830852 to
d5afa00
Compare
|
Waiting for PR #30 to be rebased and merged. This is needed to correct some failing tests in the search route. |
440f5f0 to
c799343
Compare
70a6f6b to
9661172
Compare
|
@curquiza Sorry I had to rebase it since Github informed that it was out of sync with the master. |
Yes, GitHub will inform you, but Bors will do the rebase at your place before merging 🙂 (except if you have merge conflicts. In this case you would have to rebase yourself) |
|
@curquiza @bidoubiwa Just waiting for the review now. :) |
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.
Hello @ppamorim!
Huge work!
This is the review part I 😁 I will review the test files tomorrow!
One change asked 😇
[ ] If I'm not wrong, there is no test about thefacetsDistributionofSearchResult. I mean, doing a test withfacetsDistributionas a search parameter and check that thefacetsDistributionin the serach *result are accessible. See the issue requirement (#58).
| public func encode(to encoder: Encoder) throws { | ||
| var container = encoder.container(keyedBy: CodingKeys.self) | ||
| try container.encode(query, forKey: .query) | ||
| if limit != 20 { |
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 should we need to do a condition with the default value?
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 is a filter to default parameters, so far I know these values are fixed in the server and if they are not informed in the HTTP request the server will apply the default ones, am I correct?
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 API is based in this documentation: https://docs.meilisearch.com/references/search.html#search-in-an-index-with-post-route
Note how the first example only contains the query item as mandatory, all other options are optional. This script remove the need of informing the default values.
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.
But what is the point of doing this?
if they are not informed in the HTTP request the server will apply the default ones,
Yes, exactly, so no need to check the default value. Just send to MeiliSearch what the users fill, we don't care if they fill default values. MeiliSearch will manage that.
This big if conditions are really complex for a job that MeiliSearch already does.
Or maybe I missed something!
There is a test related to this, it's named |
c199a7c to
c06f6fd
Compare
My bad! I've seen it! |
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.
Review part II
You did a so HUGE work on the tests!!!! We all know here how it's a painful job to write tests and you created a lot! Thanks for that 🙂
Some remarks:
- still the questioning here (#54 (comment)) from my previous review
- I remark, for the Settings tests , for the
getmethods, you use theupdatemethod. For me, it's a little bit redundant with theupdatetest right after: you can only check the default value of the settings.
But, as it's not really mandatory and just a detail, I'm going to open a PR to your branch to suggest changes so that it avoids you another painful work, just let me the day 😉
Co-authored-by: Clémentine Urquizar <[email protected]>
…isearch-swift into feature/integrationTest
* Add forgotten tests * Simplify GET tests for Settings * Add attribtuesForFaceting in tests * Simplify UPDATE tests for Settings * Rename wrong variables
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 PR is finally ready for a merge :)
Two points could be improved from my POV:
- the behemot (see #54 (comment)): I'm going to open an issue
- the if condition (see #54 (comment)). I'm going to open a PR with an improvement suggestion in the next few days.
Thanks again @ppamorim!
|
bors try |
tryBuild succeeded: |
|
bors merge |
|
Build succeeded: |
Summary
Reasons why the tests are failing
On the testtestGetDistinctAttributeandtestUpdateDistinctAttribute:- The attribute that returns from the server contains a double "", causing the error:XCTAssertEqual failed: ("product_id") is not equal to (""product_id"")On the testtestGetSettingsandtestUpdateSettings:- Probably due to theacceptNewFields, this has been removed.