-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
Refactor SearchIssuesRequest to match the API #290
Conversation
@alfhenrik oops, I meant to merge that in last night. Done! |
Sweeet, I'll update the skipped tests tonight 😀 |
Dun, and ready for review ✨ |
|
||
client.SearchIssues(request); | ||
|
||
connection.Received().GetAll<Issue>(Arg.Is<Uri>(u => u.ToString() == "search/issues"), Arg.Is<Dictionary<string, string>>(d => d["q"].StartsWith("pub"))); |
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.
Trim these lines at 80 char or thereabouts...
Didn't quite get all lines down to 80'ish...but should be better now. ...even an extra one in the Search Code tests...ooops..:grin: |
|
||
connection.Received().GetAll<Issue>( | ||
Arg.Is<Uri>(u => u.ToString() == "search/issues"), | ||
Arg.Is<Dictionary<string, string>>(d => d["q"].StartsWith("pub"))); |
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.
Any particular reason why you chose to use StartsWith
and Contains
rather than just hard-coding the strings?
I think tests should be tolerable, but given the possible set of query terms is large, is it worth being more terse with these checks?
EDIT: terse, not succinct. So doing d["q"] == "pub"
for example in the test above.
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'm sure there was a valid reason at the time why I went with StartsWith
and Contains
, but I'll take a look and see if we can be more terse as suggested.
That's why I said "or thereabouts" 😀 - much more easier to read now. The changes look great, just curious if we can make the tests a bit more robust... |
While testing this, I found that the query should be formatted like
I just want to check if that is an acceptable solution. |
cc @hahmed |
👍 with that suggestion |
Alright. I'll admit it, there was probably no good reason for using |
Don't sweat it. We're only human. |
@@ -25,14 +27,13 @@ public SearchIssuesRequest(string term) | |||
/// The search terms. This can be any combination of the supported repository search parameters: | |||
/// http://developer.github.com/v3/search/#search-code |
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 not test out each search request? Every qualifier too? e.g. In, Author etc.
That way we can assert each property does what it should? Quite a lot of tests to add mind you... |
That's what |
@hahmed I'd prefer to test that we're sending the correct query format to the GitHub API (harder), rather than that the parameters are populated as expected (easier). |
Just a suggestion: One thing that I was thinking about whilst I was implementing the search api was ensure everything get's appending correctly to the term. I wanted to expose a TermAndQualifiers property so we can better test the output
Then we can test what the final string should actually look like, for example github search for a user called mike:
|
I'm really interested in the external behaviour of these actions - i.e. what the client sends to the server. Testing properties in this fashion is just testing a layer away from the important bits. |
Arg.Is<Uri>(u => u.ToString() == "search/issues"), | ||
Arg.Is<Dictionary<string, string>>(d => | ||
d["sort"] == "Updated" && | ||
d["order"] == "Descending")); |
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.
Something I found last night redoing these tests is that the order parameter is coming back as Descending
, but after having a look at the API docs here http://developer.github.com/v3/search/#parameters-2 I realised the order
parameter is either asc
or desc
.
The SortDirection
enum (https://github.com/octokit/octokit.net/blob/master/Octokit/Models/Request/IssueRequest.cs#L91) values has a Parameter(Value="")
attribute applied to it, so should that automagically ✨ convert Descending
to desc
or is there something that needs to be done.
Or, will the API accept Descending
as the value of the order
parameter?
cc @shiftkey
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.
Calling .ToString()
on an enum will ignore whatever [Parameter]
you have set, so this definitely feels like a bug.
Or, will the API accept
Descending
as the value of theorder
parameter?
No, it doesn't even return valid search results
#301 was merged in, so you should be unblocked now |
👍 |
Ready for another round of review now after move to use cc @shiftkey |
Fix them projects! :) |
} | ||
|
||
/// <summary> | ||
/// https://help.github.com/articles/searching-issues#language |
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.
Could we move the URLs into a <remarks>
element and instead make a friendly sentence for each of these?
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.
Yessir!
To extract the Value field from the Parameter Attribute
instead of hard coded strings
Move URI to <remarks> field
Refactor SearchIssuesRequest to match the API
Awesome, we got there in the end :) Thanks for all the feedback! |
SearchIssuesRequest
to match current APIFixes #274