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.
Maybe you should test this class using a unit test, but with an integration/system test? Your SUT is not your domain, it seems to be an infrastructure component. To test it, you heavily rely on mocks. If you have to mock out everything, it's usually a smell that a wrong kind of test has been chosen or tour system boundaries are not right.
ReplyDeleteAnd don't worry, I wrote a lot of similar tests :)
Thank you very much for your feedback, Marcin.
DeleteI'll try to do what you say.
Best regards,
M
This comment has been removed by the author.
ReplyDeleteOne would think that classes using the FormEmailComposer would use the EmailSender as well, so what about creating a façade service that encapsulate everything about emails?
ReplyDeleteThat way, you'd have an EmailService with 2 collaborators: FormEmailComposer and EmailSender. And this class would reduce the dependencies by one.
Also, as I understand it, this class is an action that depends on the state of the form collaborator. So what about passing the form object as parameter to the "sendByEmailAndRedirect" method, instead of injecting it in the constructor?
With those changes, your constructor has now only 2 dependencies. What do you think?
It sounds good. I'll try your idea.
DeleteThank you very much for your feedback.
Best regards,
M