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

[DX] Mocks should fail immediately #508

Open
Jean85 opened this issue Oct 27, 2020 · 1 comment · May be fixed by #509
Open

[DX] Mocks should fail immediately #508

Jean85 opened this issue Oct 27, 2020 · 1 comment · May be fixed by #509

Comments

@Jean85
Copy link
Contributor

Jean85 commented Oct 27, 2020

I was having some attrition while using Prophecy in my PHPUnit tests, and I track it down to mocks going further with unexpected calls.

I've opened phpspec/prophecy-phpunit#27 thinking that the root issue was the migration from the old, deprecated PHPUnit integration to the new trait one, but I discovered that it wasn't, and instead it was #457 that, in 1.10, made this change.

That issue was closed by @ciaranmcnulty with:

Yes, I think if faulty tests were wrongly passing before we don't need to consider it a break.

... but I'm here to ask for a revert, or at least a switch to enable the old behavior back.

Why do I need this?

I would like to go back to mock failing hard and fast because writing (or altering) tests with this new behavior is extremely frustrating:

  • if the mocked class has a return type that doesn't allow null, I get a \TypeError (as pointed out by @stof in https://github.com/phpspec/prophecy/pull/441/files#r388191626)
  • if the mocked class has a return type that does allow null, I get a null that goes further in the SUT, often delaying the test failure and making it really obscure to track it down

In both those cases, it's often the case of getting the mock's expectation slightly wrong, but I have no way of discovering it: I always have to widen it up until it matches and I get a green test, and then go back, making the expectation narrower as desired.

Is it possible to get the old behaviour back? Or to have a way to opt-out from this new behaviour? I understand that #441 was not considered a BC break because code as is had to be correct anyway, but while changing code this is really frustrating!

@Jean85 Jean85 linked a pull request Oct 27, 2020 that will close this issue
@Jean85
Copy link
Contributor Author

Jean85 commented Oct 27, 2020

I drafted a solution in #509

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

Successfully merging a pull request may close this issue.

1 participant