-
Notifications
You must be signed in to change notification settings - Fork 29
Conversation
|
||
foreach ($operationStack->getPersistStack() as $document) { | ||
$dm->persist($document); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The operation stack will also contain a list of documents to remove, potentially. (although for now I am going to make the PHPCR-ODM driver bypass the ODM because its buggy).
Added unit test for the |
I really love Behat, so no. Except that we choose to stick with PHPunit only, so a new contributor only has to learn knowledge about PHPunit and not about other tools as well. If we step of that, I also prefer to use PHPspec for unit tests, or use another mocking framework like Mockery or Prophecy.
Ok, thank you for starting on with this. I'll see if I can take it somewhat further :) |
@@ -1,139 +0,0 @@ | |||
<?php |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should be readded
Added a unit test for the UrlGenerator using Prohpecy just as an experiment. Much easier than PHPUnit but we will need to create a base test class. Also rebased on lastest metadata changes. |
->willReturn($tokenProviderConfigs); | ||
|
||
$this->metadata->getUrlSchema()->shouldBeCalled() | ||
->willReturn($urlSchema); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a code smell you have learned from PHPunit mocks/mockery, which you shouldn't apply to Prophecy.
You almost always have 2 types of methods: Query and Command. A query method returns a value and a command method contains logic to handle values. Query methods should have promises (e.g. ->willReturn()
), while a command method should have predictions (e.g. ->shouldBeCalled()
). Only in some rare cases, there is a method which is both a query and a command (this violates CQRS). In that case, you can use both promises and predictions on one method.
In this test, all mocked methods are query methods which should only get promises. We shouldn't test if a getUrlSchema
is called, the only thing we need to define is what it returns in case it is called.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
makes sense, wasn't 100% about adding those. What would be an example of a Command method? something that does not contribute to the return value but should be called anyway? (like an API call to a web service?)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For instance, $documentManager->persist($doc)
is a command method. $context->addViolation(...)
is one too.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
And a case in this bundle: When testing UrlGenerator#resolveConflict()
the ConflictResolver#resolveConflict()
method is a command.
- Droped per token/provider exists/not_exists - Abstracted all database logic to driver - URLs now treated as entire URLs, not they're component parts - Support for handling old routes
- Used prohpecy as an experiment - Rebased on the new metadata implementation
- Renamed driver to adapter -
Rebased and added unit test for the PhpcrOdmDriver. I am about ready to start writing functional tests. @wouterj would you be in favor of introducing behat? |
|
||
// bypass the ODM ... but changes will still only be | ||
// persisted when the PHPCR session is saved in the ODMs flush(). | ||
NodeHelper::createPath($this->dm->getPhpcrSession(), $parentPath); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This static call is a pain because I have to mock both a PHPCR SessionInterface
and also an associated expectation to return a NodeInterface
. @dbu do you think there is any scope for adding an instantiable version of this class in PHPCR utils? would make testing easier :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yeah, whenever you try to cheat you get caught sooner or later :-(
i was too lazy to pass those helper all around the place. we can't even make the SessionInterface provide this, as its only in phpcr util. if we had built this as a class with methods, we could allow to set the helper and have a getter that creates the instance if its not set. but this would be a major BC break to change that now. we could introduce a new class in parallel but the best name is already taken. and whatever we do, it won't be phpcr-utils 1.1 but 1.2 so i fear right now we do need to mock. but open an issue on phpcr-utils that we should fix this there, and in jackalope and phpcr-odm.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Created: phpcr/phpcr-utils#106
I like behat, so I have nothing against it. :) |
continues in #72 |
OK this is basically a rewrite.
Note I deleted all the providers just to be Zen - but I will probably pull them back in later.
Now my head really hurts .. but the good news is that the code is much easier to follow.