Whenever a method is called on the $logger dummy, it will return null. When a particular type of object is required as an argument, but it is not used in any significant way, use a dummy. I already mentioned that there are many different types of test doubles that you can use in your tests (there is a nice article about these types of test doubles by Robert Martin, called The Little Mocker. This is why you want to build some flexibility into your test doubles ( let's call them "test doubles" from now on, that will make things much more clear). When you refactor the code of the class you are testing, it's possible that the order of function calls changes or that maybe one function is called twice. If you are too rigid about the number of times a method is called, the order in which methods are called or the arguments used when calling a method, your test will easily fail whenever you make structural changes to the SUT. Why do I have these kinds of concerns? It turns out that if you are not aware of these issues, mocks can badly influence the stability of your test suite. Is it even necessary to check the argument ( $object) which is used when the validate() method is called)? And are you aware that by default PHPUnit checks only equality of the argument, not sameness (which in particular matters when the actual object and the expected object should have been exactly the same object).Is it important that the validate() method is called exactly once? Shouldn't it be possible to call it twice and get the same result in both cases?.There are some more concerns or questions that need to be answered about this code: It is not at once clear that the resulting validator "mock" never successfully validates an object, when called it will always return a violation list with one violation.It is not clear which types of test doubles are used.Besides readability issues, this code has some more problems: >will($this->returnValue($validationViolationList) Ĭode like this is pretty hard to read, although you will get used to it when you use PHPUnit for a long time. $validator = $this->getMock('Validator') $validationViolationList = $this->getMock('ValidationViolationList') But your tests may still be quite unreadable because they contain long lists of set-up code for all the mocks that your Subject Under Test (SUT) requires, like this: $object =. The assertions themselves are hidden from sight. Even better: they describe what is going on and what the outcome of each test should be. If you have followed my advice from the previous article, your unit tests are not assertion-centric anymore. Each type of test double has its own merits and it is vital to the quality of your test suite that you know when to use which one. I can say after writing lots of unit tests for a couple of years now that my testing experience would have definitely been much better if I had known about the different kinds of test doubles that you can use in unit tests. In reality, a mock is a very particular kind of test double. The word "mock" in the context of PHPUnit is given the meaning of the general concept of a "test double". Most unit testing tutorials cover this subject by introducing the PHPUnit mocking sub-framework. In the introduction to this series I mentioned that testing object interactions can be really hard.
0 Comments
Leave a Reply. |
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |