![]() Imagine a service to testįor the sake of argument, I've written a simple content negotiator class for an API which can return data in multiple formats. ![]() This is the contention I want to explore in today's blog post. My contention, however, is that these cases are a rare exception, that - particularly in the PHP community but also more broadly - mocks are vastly overused and over-relied on, have a tendency to lead to badly constructed, uninformative, brittle tests and are simply neither needed nor preferable in the majority of cases. Sometimes we have complex business logic interacting with dependencies in such a way that it's difficult in practice to test without making direct assertions about how the dependency was used. This is, on occasion, a legitimately useful thing to do. In PHP, they are instantly recognizable by code which looks like this: $mockFoo->expects($this->once())->method('bar')->with($this->equalTo('baz')) Mocks are a type of test double which make assertions on how the object will be used what methods will be called, what order, how many times, with what parameters. If you've written a unit test, you've (almost definitely) written mocks. If you've ever seen a unit test, you've seen mocks. Better PHP unit testing: avoiding mocksīetter PHP unit testing: avoiding mocks What are mocks?.The test I was stuck on was one where an unhandled exception was thrown, and the script basically shuts itself down having first logged what went wrong. And the logger is one of these dependencies, and is also mocked. A lot of it is fairly perfunctory "belt and braces" sort of logging, say "Records 1000-1999 processed OK", and I don't really care about that but there's other stuff where the script deals with unexpected circumstances and I want to make sure that's done right.įor the purposes of this test I am mocking out all the dependencies so the script doesn't actually do anything, but the mocks return "workable" mocked data sufficient to walk through the stages of the script. The upshot of this is the script logs a bunch of stuff - said script will be run by a cron job - and part of my testing is to verify the right things gets logged at the right time. I don't mean that judgementally: all code bases have better and not so good code in them. ![]() And in the course of doing this work I turned-up a coupla bugs and had to fix those, so I don't back our own code to be stable here. well yeah they were written in a different era by people with an unusual understanding of how to write managable, testable, and reliable code. Firstly I'm talking to an external third-party service, and it's foolhardy to trust those secondly I'm relying on some of our own internal services which. but to someone, apparently.), and I want to make sure we can track when things go wrong. ![]() The details are irrelevant, but it's fairly "important" data (well: not to me. I do so look forward to being told about it.Īnyway, I'm writing a script to repair some bung data we have. I'm sure there's strong opinions held on this sort of thing somewhere as to how I'm not supposed to want to do what my requirement has me needing to do here. I think it's quite handy and works around what seems to be a shortcoming of how PHPUnit mocks stuff. This is just a quick PHPUnit one, inspired by a trick my team lead suggested to me.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |