-
Notifications
You must be signed in to change notification settings - Fork 11.5k
[5.0] Much verbose output in assertResponseStatus() method #8253
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
Much verbose output in assertResponseStatus() method, where the output tells what was expected, what is actual.
@@ -14,7 +14,7 @@ public function assertResponseOk() | |||
{ | |||
$actual = $this->response->getStatusCode(); | |||
|
|||
return PHPUnit::assertTrue($this->response->isOk(), 'Expected status code 200, got ' .$actual); | |||
return PHPUnit::assertTrue($this->response->isOk(), 'Expected status code 200, got ' . $actual); |
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.
Don't put spaces in between each dot.
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.
With all due respect, are you going to reject people's PRs just because there is a bloody space in between dots? How do you recommend I put spaces around dots in the line below (I put spaces here for more readability and style-unity with the line I added)?! Does this project has some coding guidelines I missed? Because what you ask doesn't even relate to PSR guidelines. Correct me if I am wrong. I do bloody care about this project as much as any developer who uses it in a daily basis. Please show some understanding! :( Have a good day!
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.
No, Taylor is asking you to change it.
Does this project has some coding guidelines I missed?
Our code style is self documented by our code. The same goes for Symfony.
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.
@GrahamCampbell , @taylorotwell isn't 5 year old kid who can't speak for himself. Stop jumping into every convo mate. Reject the PR, I am sure those spaces mean more to this project than our contributions! And I don't care about Symfony, I am not sending this PR to Symfony.
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.
@shehi Since you mentioned PSR guidelines, you probably know how important a consistent code style is for projects as large as this one.
Your PR looks good except for this small issue - it would be awesome if you could fix this. In fact, you can also interpolate the variables directly in a string with double quotes - that's also fine by Laravel's standards:
"Expected status code 200, got $actual"
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.
@shehi Your PR was not rejected. On the contrary, the fact that Taylor asked you to fix the whitespace to match his style indicates that he wants to accept this change.
The laravel docs have some very basic coding guidelines, but it can't possibly cover everything. Anything that is not covered there, can be understood from reading Laravel's source code. If anyone sends a PR where the format does not fully match Laravel's coding style, it is kindly pointed out to them, they change it, and then the PR can be accepted.
Also, keep in mind that Taylor is just one person and he can't possibly get to everything himself. @GrahamCampbell has been generously giving much of his own time to help Taylor out with fielding issues and pull requests, so that Taylor can focus on the actual code.
P.S. you don't have to submit another PR. You can update this one. After you make your changes, run this command:
git commit -a --amend --no-edit
git push -f origin patch-1
This will update the current PR with the changes you've made.
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.
@JosephSilber , original line already had space to the left of dot. I just added one to its right. It already had so called standards "violated". Anyway, let's get this over with. Fixed! Now the space to the left is deleted. Don't bloody ask me to put it back in! :)
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.
Yeh, none of us get paid for Laravel, though Taylor has an income for Laravel related products.
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.
Our code style is self documented by our code. The same goes for Symfony.
This is not entirely precise for Symfony. We do have a document explaining our code standard rules.
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.
That document is incomplete though. I work on php-cs-fixer, and changes are made to symfony's official coding standards by us merging cs changes into symfony/symfony. Our code gets used in fabbot.io which checks all symfony pull requests. That's why I said symfony's code is selfdocumenting - because it actually is.
@@ -25,7 +25,7 @@ public function assertResponseOk() | |||
*/ | |||
public function assertResponseStatus($code) | |||
{ | |||
return PHPUnit::assertEquals($code, $this->response->getStatusCode()); | |||
return PHPUnit::assertEquals($code, $this->response->getStatusCode(), 'Expected status code '.$code.', got '.$actual); |
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.
"Expected status code $code, got $actual."
would be much better btw.
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.
Wait until we get some complex objects interpolated into strings, then you won't sound so funny :) I will do it as you ask (noticed inside the same file, down below, everything is inside the string, instead of being concat'ed).
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.
@shehi That would been an issue anyway. PHP would have behaved the same when you try to concatenate them.
@@ -14,7 +14,7 @@ public function assertResponseOk() | |||
{ | |||
$actual = $this->response->getStatusCode(); | |||
|
|||
return PHPUnit::assertTrue($this->response->isOk(), 'Expected status code 200, got ' .$actual); | |||
return PHPUnit::assertTrue($this->response->isOk(), "Expected status code 200, got $actual"); |
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.
Shouldn't we end in a full stop?
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.
Thought about that, but the original code didn't have that. And full stop (the dot) is a character by itself: in a context where you compare the expected with the actual, I think introducing additional chars would be a bad idea.
This looks much better now, thanks. Could you squash to one commit at the end please? |
@GrahamCampbell , I am editing code directly on GitHub. Didn't bother to fork it locally. Is there a way to squash it over here? |
@GrahamCampbell : feel free to squash it even if it means the change of author. Or wait til tomorrow, its midnight here right now. Or decline this PR, I will create new PR quickie and send in. |
We can technically squash on merge, but that rarely happens. |
Please do, as long as we don't damage anything, its fine by me :) |
@@ -25,7 +25,7 @@ public function assertResponseOk() | |||
*/ | |||
public function assertResponseStatus($code) | |||
{ | |||
return PHPUnit::assertEquals($code, $this->response->getStatusCode()); | |||
return PHPUnit::assertEquals($code, $this->response->getStatusCode(), "Expected status code $code, got $actual"); |
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.
$actual
is not degined here.
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.
Fixed. @GrahamCampbell could you please merge this by squashing it in the process? Authorship isn't really important for such a minor enhancement. Thanks.
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 can squash and still keep your authorship on the commit.
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.
@GrahamCampbell ok, just do it :)
@taylorotwell , @GrahamCampbell : please merge by squashing. PR author-ship isn't really important for this tiny piece of code. Or just decline and add the code in your next update yourself. Thanks. |
[5.0] Much verbose output in assertResponseStatus() method
Much verbose output in assertResponseStatus() method, where the output tells what was expected, what is actual.