Sometimes one might even think so (actually today for some moments I did). The story: one of our factories "left out" a property, meaning that we simply forgot it, both in tests and codebase. Do I hear someone say "then what are tests for? they are useless as they didn't trap your error"? well the someone I'm thinking about is on holiday so I'll be spared that, but she would be right on one thing: the test, these unit tests at least, did not trap MY error (assuming I wrote that part of the code).
So what? this oversight, when corrected (test first of course), caused some tests related to distant classes to fail, not because the correction was not right, but because the freshly failing tests needed to be updated.
Foolishly, I didn't run the complete suite of tests for the project before committing, so my CI server wrote me that I broke the build. This happened twice.
I must confess it was anoying: I had to add more code to correct the wrong assumptions of the test. This conceptually disturbed me, as I didn't have to fix the code (which was already correct) but the tests (it just so happened it was because I was using a mocking library and I had to set another couple of expectations).
This pushed me to a couple of considerations.
First, it is true that sometimes mocking libraries introduce a dependency you could happily live without.
Second, I would have avoided to trigger a remote build if I ran the whole suite of tests. The problem is that it would have take too long compared (in my opinion) to the small changes I made. Once more, I slammed my face on the wall, so I think I'll play ball by always applying the "Run Private Builds" pattern, that in the end would have saved me time.
Il risparmio alle Coop
6 days ago
6 comments:
> it just so happened it was because I was using a mocking library and I
> had to set another couple of expectations
this problem in unit tests usually is a smell about a design problem.
when there are 2 places where you need to change an expectation and not the code probably the design is broking the Law Of Demeter.
since you are talking about properties this is very likely.
You're right, the design IS breaking the law of Demeter, but I can live with that as the second place in which I had to change the expectations relates to a mapper for a different bounded context (basically we're talking about a factory for a one-way DTO).
This is partially justified by the fact that the law is broken almost only here, thus adding the delegating methods would only result in useless noise for the rest of the application.
After all, laws can be broken (these ones, at last), but first you must know them, at least to have an idea of the extent of the consequences.
... I thought you were talking about rugby test matches ;-)
@Pancho that's because you had too much Zibibbo lately :-)
to be fair I used to puch* sesame biscuits into lipari's malvasia every day...
* to puch: pucciare
I'd say "dip" instead, but it would spoil all the poetry associated with the act :-) see you (all) at the Milan Rugby Festival in Cernusco next weekend
Post a Comment