unit testing with DI

I have a question concerning dependency injection. I have been keeping it simple so far, my methodology is basically to factor out object creation within objects and passing it instead in the constructer. I have come to a point where I am attacking larger classes that require multiple oblects. Some even have objects that contain other objects, with merry little singletons here and there. It gets ugly fast when testing these classes, as they are far from 'isolated' they are still hard-coded to their dependencies.

So. Injecting an object or 2 for a trivial class is straightforward,

I have looked into dependency containers, saw many implementations and am now wondering what is the advantage of using container vs. a registry for example. Couldn't one just as easily use a registry to hold anonymous functions that create the needed dependencies when called upon?

The 2 containers I peeked into, Php Dependency and Pimple differ greatly in the implementation.

I am wondering on the advantages of user a container vs. passing straight objects. I fail to understand how php-dependency's implementation would be tested, 开发者_Python百科ie how would one implement the mock database object in phpunit without the actual class being injected when tested? Is there advantage to having dependency mapped out and used in doctags like this?

Class Book {

  private $_database;

  /**
   * @PdInject database
   */
  public function setDatabase($database) {
      $this->_database = $database;
  }

}

Pimple, on the other hand takes a totally different approach. No docblock tags, no mapping in seperate file, it seems like some kind of souped up registry ....

  Objects are defined by anonymous functions that return an instance of the object:

 // define some parameters
 $container['cookie_name'] = 'SESSION_ID';
 $container['session_storage_class'] = 'SessionStorage';

... that can behave as a factory at same time:

$container['session'] = function ($c) {
    return new Session($c['session_storage']);
};

Declaring shared ressources always serves the same instance (singleton!?):

$c['session'] = $c->share(function ($c) {
return new Session($c['session_storage']);
});

This is were I got the idea of using a simple registry that holds either objects or anonymous functions. BUt am I missing something in this approach? Pimple, I can see to how to test, but Php-Dependency is unclear to me from a testing point of view.

Normally in our apps, we do constructor injection and define an interface for all components in our system:

class Book
{
    /**
     * @var Db_AdapterInterface
     */
    private $_database;

    public function __construct(Db_AdapterInterface $database)
    {
        $this->_database = $database;
    }
}

We have then of course a standard Db_Adapter and then another Db_TestAdapter. In Db_TestAdapter we can define results of SQL queries in our tests.

For our normal app, we have something like this for our container:

$container->add('Db_AdapterInterface', new Db_Adapter());

And then in our tests, we have this line instead:

$container->add('Db_AdapterInterface', new Db_TestAdapter());

To get an instance of a Book, we simply ask the container for it:

$book = $container->construct('Book');

And the container injects all the needed dependencies into the object.

If you keep all your objects loosely coupled, ie object A only needs an interface B then you can always provide object A with a test implementation. At that point what container you use doesn't matter.

We have a very simple IoC container which can do basic constructor injection. Our tests inherit from a base class which fills the container with standard test objects. That way we don't have a lot of code just to construct an object we want to test.

Update: I added an example of wiring things up in the container.