Skip to content
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

Use a more strict parameter equality comparison by default #231

Open
still-dreaming-1 opened this issue Feb 8, 2017 · 2 comments
Open

Comments

@still-dreaming-1
Copy link

When it comes to testing, I am a big believer in strict equality comparison by default. I think the default way of comparing equality is too loose in most test frameworks / libraries. I think most of them get it backwards. By default they use loose equality comparison and you have to invoke a specialized, less convenient way of doing a most strict equality comparison. I think when comparing whether or not a certain parameter was passed, whether that be when deciding on an answer for a stub or when verifying method call parameters, the default behavior should be to require the types to "match", more or less, and the values to be "the same". For example, the string "0" and the int 0 should by default not be a match. You should have to do something special to compare them in a less strict way.

I can see the opposing viewpoint when reasoning about this on an abstract level, but that viewpoint seems to based around being annoyed with the reality of the situation despite not having found a better solution. On an abstract level it seems to make sense that our tests should not be too specific. If they are very specific, it seems the tests are a duplication of the code being tested. Sometimes the the tests seem to break too easily as a result of changes in the code being tested. That is an annoying problem, and there may be a solution to it, but this is not it. The reality, as annoying as it may be, is that our tests are largely about duplicating logic and details by expressing them in a different way. If the two witnesses, the mind of the coder interpreting the code they wrote, and the results of the tests report the same thing, it is much more likely to be true. There may be a better way, but the PHP community has not adopted one yet.

When it comes to writing real world tests, it is largely about trying to verify that what we think is true about our code really is true. When we think a method will get called with a 0, most of the time we would be surprised if it actually got called with a "0". Even if it does not necessarily matter what the type was, it would usually be a little disturbing to us if the type was different than expected, and this would normally motivate us to dig deeper to make sure something is not awry. It would be nice if our tests could be about verifying the design of the code, and if the design could be based on the ideal one, where the types don't normally matter. But when the code is allowed to work with multiple data types in this way it becomes too difficult to reason about and feel confident it will always interact with other code in the expected way. It is easier to narrow down the type possibilities at each point than to always allow for a plethora of them.

@JKingweb
Copy link
Contributor

I would also like to see this as a configuration option, especially for Phake::when().

@willemstuursma
Copy link
Contributor

You can wrap your expected values in $this->identicalTo($expectedValue) when matching with ::when() or ::verify().

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants