TYPO3 Flow Base Distribution

I want to throw in https://github.com/sebastianbergmann/php-test-helpers

This is called "test-helpers", however it is exactly useful for overwriting the new operator to implement AOP.

Hey,

as already discussed with you @Robert, I don't see this as a high priority right now. Just wanted to add this to the issue, so it does not get lost :-)

Greets,
Sebastian
PS: @Benjamin: It's great that you're active here, helping us with the Doctrine evaluation :-)

An important argument against using the new operator is testability. If classes create their own prototypes (prototypes in the context of FLOW3), there is no easy way to mock them. That's exactly the reason why PHP-test-helpers were developed.

On the other hand, if we can afford to require the use of such a custom PHP extension for testing then it might make sense to keep on exploring this topic.

Hm I disagree!

You already mention prototypes in the context of Flwo3and mix it with php test helpers. Your reasoning would imply that php-test-helpers was developed for Flow3. It was developed for applications that don't use dependency injection.

But Dependency Injection is independent of the problem newable vs injectable, which is discussed here:

http://misko.hevery.com/2008/09/30/to-new-or-not-to-new/

and also in Evans Domain Driven Design (Entities and Services chapter).

I don't say you ObjectManager::create is bad per se. Its just bad for "newables" (Entities, Value objects and such).

Benjamin Eberlei wrote:

You already mention prototypes in the context of Flwo3and mix it with php test helpers. Your reasoning would imply that php-test-helpers was developed for Flow3. It was developed for applications that don't use dependency injection.

But Dependency Injection is independent of the problem newable vs injectable, which is discussed here:

http://misko.hevery.com/2008/09/30/to-new-or-not-to-new/

Misko argues that there's no need to mock "leafs of the application" because they are more or less like strings. I don't agree with that. I can easily imagine Entities which rely on a complex set of other objects which I'd rather unit-test separately and not alltogether. If I test a "Conference" object I want to see my test pass or fail because "Conference" is implemented right or wrong. It's confusing to see "Conference" tests fail because the "Address" object used by the "Venue" object created by the "Conference" object is buggy.

and also in Evans Domain Driven Design (Entities and Services chapter).
I don't say you ObjectManager::create is bad per se. Its just bad for "newables" (Entities, Value objects and such).

Hmm, I don't know. I guess you can produce okay code either way, it's rather a question of style. What I find appealing with the new-operator approach is that it a) doesn't require an Object Manager and b) is less to type. However, the ObjectManager->create() approach is easier to mock and more explicit about who's responsible for object creation.

Certainly, we could go for a mixture of both (like Symfony tends to do), but that's the option I dislike most. I'd rather have everything consistent following the same conventions.

Miskos main argument is not about the leafes of an application, its about hard to test code if you violate the injectable vs newable rule, because in this case to be able to test newables you might need injectables. This is cumbersome to setup. In the case of FLOW3 its easy to explain:

Why do i need to configure tons of mocking lines just to be able to test my simple "BlogPost" entity. Its supposed to be a domain object, not knowing anything about technical blabla such as an object manager. There is a a considerable difference between:

class BlogPost
{
    public function addComment($message, $email)
    {
         $comment = $this->objectManager->create("Comment", array($message, $email));
         $this->comments[] = $comment;
         return $comment;
    }
}

class BlogPost
{
    public function addComment($message, $email)
    {
         $comment = new Comment($message, $email);
         $this->comments[] = $comment;
         return $comment;
    }
}

in regards to testing:

class BlogPostTest
{
    public function testSimpleNewable()
    {
        $post = new BlogPost();
        $comment = $post->addComment("hello world!", "kontakt@beberlei.de");

        $this->assertType("Comment", $comment);
        $this->assertEquals("hello world!", $comment->getMessage());
        $this->assertEquals(1, count($post->getcomments());
    }

    public function testComplexObjectManagerTest()
    {
        $message = "hello world!";
        $email = "kontakt@beberlei.de";

        $objectManager = $this->getMock('Some/Very/Long/PathTo/ObjectManager');
        $objectManager->expects($this->at(0));
                     ->method('create');
                     ->with($this->equalTo('Comment), $this->equalTo(array($message, $email))
                     ->will($this->returnValue(new Comment($message, $email));

        $post = new BlogPost();
        $post->setObjectManager($objectManager); // rather simple, but what if you rely on reflection only here in your model?
        $comment = $post->addComment("hello world!", "kontakt@beberlei.de");

        $this->assertType("Comment", $comment);
        $this->assertEquals("hello world!", $comment->getMessage());
        $this->assertEquals(1, count($post->getcomments());
    }
}

This is miles apart in terms of simplicity. Because test two violates the rule, never depend on injectables in your newables.

Please also review the section on factories and aggregate roots in DDD, it specificially says entities / aggregate roots can create objects themselves not some object manager.

Additionally the current approach means that you need the object manager as reference in EVERY object. Becaues whenever i want to create a new object I also need an object manager. That all just leads to very complicated and repetitive code. (as shown in the above test-example).

So how will this work? Your tweet about it didn't release any technical details :-)