undefined | Better HN

0 pointsjtreminio12y ago0 comments

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.

0 comments

contingencies12y ago

Procedural testing isn't hard.

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.)

bencoder12y ago

I think you've missed the point. If your procedure calls other procedures, how do you test its functionality individually? How do you know if the problem exists in the procedure itself or one of the procedures it calls. Without DI in some form you are stuck with your procedures being tightly coupled together.

Gigablah12y ago

You can still mock the Foo class... by using class_alias.

Don't tell anyone else, though :p

j / k navigate · click thread line to collapse