/home/techb158/dev.balacoffee.com/vendor/mockery/mockery/docs/reference
NameSizeModeActions
alternative_should_receive_syntax.rst23810644editdlrm
argument_validation.rst107450644editdlrm
creating_test_doubles.rst144620644editdlrm
demeter_chains.rst16390644editdlrm
expectations.rst159460644editdlrm
final_methods_classes.rst13510644editdlrm
index.rst4210644editdlrm
instance_mocking.rst8050644editdlrm
magic_methods.rst6870644editdlrm
map.rst.inc5500644editdlrm
partial_mocks.rst42860644editdlrm
pass_by_reference_behaviours.rst43220644editdlrm
phpunit_integration.rst48530644editdlrm
protected_methods.rst6680644editdlrm
public_properties.rst8210644editdlrm
public_static_properties.rst7010644editdlrm
spies.rst47360644editdlrm
Edit: /home/techb158/dev.balacoffee.com/vendor/mockery/mockery/docs/reference/magic_methods.rst (687B)
.. index:: single: Mocking; Magic Methods PHP Magic Methods ================= PHP magic methods which are prefixed with a double underscore, e.g. ``__set()``, pose a particular problem in mocking and unit testing in general. It is strongly recommended that unit tests and mock objects do not directly refer to magic methods. Instead, refer only to the virtual methods and properties these magic methods simulate. Following this piece of advice will ensure we are testing the real API of classes and also ensures there is no conflict should Mockery override these magic methods, which it will inevitably do in order to support its role in intercepting method calls and properties.