Showing posts with label Phake. Show all posts
Showing posts with label Phake. Show all posts

Tuesday, April 1, 2014

Introduced FormEmailService façade and struggling with names again

Following the advice given by One on a comment, I introduced a façade service that encapsulate everything about emails, FormEmailService with FormEmailComposer and EmailSender as collaborators. This simplified the creation of the IntroducedInformation class which was great.

I also followed his suggestion of passing the form object as a parameter to the sendByEmailAndRedirect method.

This was how it was used after that change:

Although the creation of the IntroducedInformation got simpler, I didn't like how it read anymore because an "information thing" was now sending a form.

In the previous version the "information thing" was sending itself using a "Yoda-like" language:

To keep the form as a parameter I decided to rename the class to so it was "something that does something on something" and not finding any better name I went down the road of "SomethingService" names:

Well, it's not perfect but at least I think it reads better than the version where the "information thing" was sending a form.

This is how the class looks now:

and these are its tests:
I keep thinking in a name for this that doesn't follow the "SomethingService" pattern, but until inspiration comes I'll settle on this one.

Thank you very much Carlos, Marcin and José for your feedback. I really appreciate it.

Monday, March 31, 2014

Finally some better naming but still with fragile tests

After sleeping on it I've found better names for the examples I've recently posted about (see preious post).

The obstacle was seeing it as an action on a form. Thinking instead on information that needs to be introduced and sent made the names flow much better.

This is the resulting class:
and these are its tests:


Finally, this is how it's used now:



I'm much happier with the naming now.

The tests are still fragile, but by using helpers in the tests the amount of places where the mocks are used gets reduced.

Refactored my clumsy tests

I've reworked the class and the tests I showed in my previous post.

This is the refactored class:

The responsibility to compose an email from the form fields was delegated to the FormEmailComposer collaborator whereas the responsibility of sending the email was delegated to the EmailSender collaborator.

The Redirection collaborator is still in charge of the redirecting responsibility.

Now the Form and the Email class are just value objects.

These are the new tests:

And this is how I'm using the SendingAndRedirectionAction class:

I'm a bit happier with the naming and I also reduced the number of classes.
However I'm still concerned about the tests fragility.

Saturday, March 29, 2014

First clumsy tests using Phake test doubles framework

Two weeks ago I started learning PHP for my new job at Runroom.

It's my first job as a web developer so I'm still a bit "lost".

Today I tried to write unit test for this class in order to learn how to use Phake test doubles framework:
These were the resulting tests:
Although I like the readability of the tests, I'm not very happy with them because I think they will be too fragile. At the same time I'm not sure how else I could test the behavior of SendingFormByEmailAndRedirecting class...

To give you a bit more of context this is how I'm using it from my code: