To grow as a developer, there is nothing as good as opening up your guard and invite others to criticize your potential flaws…as well as reading a book every now and then.
In real life, you have to be a pragmatic programmer (provided that you are, in fact, a programmer) and do what is “best” for the project, even if that means getting a project released instead of developing it to the point of perfection.
In hobby projects, however, I more than often find myself reaching for this very perfection.
(Note: My earlier attempts to reach perfection involved having separate, standardized regions for variables, properties, methods, constructors etc. as well as writing comments for all public members of every class. I was ruthlessly beaten out of this bad behavior by http://twitter.com/#!/nahojd – who has my eternal gratitude)
Now, I suspect that I have become trapped in another bad behavior – the unit test everything trap. At its worst, I may not even be writing unit tests, so I invite all readers to comment on if I am out on a bad streak here.
The standard setup
In the standard setup, I have:
- IGroupInviteService – the interface for the service has several methods, e.g. AcceptInvite and CreateInvite.
- GroupInviteService – a standard implementation of IGroupInviteService that handles the core processes, with no extra addons.
- GroupInviteServiceBehavior – a test class that tests every little part of the standard implementation.
This setup works great. It is the extended e-mail setup below that leaves me a bit suspicious.
The extended e-mail setup
In the extended e-mail sending setup, I have:
- EmailSendingGroupInviteService – facades any IGroupInviteService and sends out an e-mail when an invite is created.
- EmailSendingGroupInviteServiceBehavior – a test class that…well, that is the problem.
The EmailSendingGroupInviteService class
Before moving on, let’s take a look at how the EmailSendingGroupInviteService class is implemented.
As you can see, the e-mail sending part is not yet developed 😉
As you also can see, the methods only call the base instance. Now, let’s look at some tests.
The EmailSendingGroupInviteServiceBehavior class
Let’s take a look at some of the EmailSendingGroupInviteServiceBehavior tests.
As you can see, all that I can test is that the base instance is called properly, and that the base instance result is returned.
Testing the decorator class like this is really time-consuming, and for each new method I add, I have to write more of these tests for each decorator class. That could become a lot of useless tests.
Well, the tests are not useless…they are just…well…I just hate having to write them 🙂
So, this raises my final question:
- Would it not be better to only test the stuff that differ? In this case, only keep CreateInvite_ShouldSendEmail