|
|
|
|
|
|
by jtreminio
4642 days ago
|
|
|
These tools only work when: 1) You've implemented dependency injection, or 2) You're using a container For example, in PHP you can't mock something like "$foo = new Bar();". The code is right there, it's saying exactly what it wants, you can't return a fake class (unless you do some ugly magic). However, you can pass in an object that is_a Bar, either injecting it via DI or storing it and then retrieving it from a container. With code like Foo::Bar() - that's it. You're tied to the Foo class, Bar() method and you can't change a thing about this. |
|
|
All that dependency crap is only a result of your AbstractTestingFrameworkMethodFactoryClassMockMethodGenerator() and similarly useless abstractions, anyway.
A simple module system can be implemented in a single function and referenced from test code as easily as:
test_requires('module1','module2');
Purely procedural tests are as easy as:
assert_equals(function_one('example_input'),'expected_output'); assert_not_equals(function_two(true),false);
Full featured test framework:
function assert_equals($a,$b) { return $a==$b; } function assert_not_equals($a,$b) { return $a!=$b; }
(Edit: I don't believe I missed the point - 'dependency injection', a recent term in PHP, essentially means tightly coupling to an entire DI system instead of directly to a single dep as demonstrated above. Either way, loose coupling is a concept to strive for as far as reasonably possible - not an absolute requirement. If your code requires something else, then it requires something else. The solution is not to create a new AbstractPretenderOfTotalWorldVisibilityEvenThoughControlFlowIsNowAllOverTheShop() After all, if you carry that tight coupling argument further you could claim that by virtue of writing PHP at all you are tight coupling to a certain, if broad, class of processor architectures. There has to be a limit somewhere! Mostly, that's determined by legibility/maintaintability and programmer time, not by abstract measures of correctness.)