|
Is it worth testing the return type and value of a method call that is designed for chaining? It is conceivable that a fellow programmer could accidentally change the return type to void and remove the return while furiously refactoring some methods? This would potentially break a lot of code for an unsuspecting user. However, I feel like I would be testing code structure rather than code functionality. Is this a reasonable thing to test? Or is it just a big waste of time? |
||||
|
|
|
If the chainable method constitutes a unit, then by all means unit-test it. If it is only used internally, and thus easily subject to refactoring, leave it alone and unit-test the exposed methods that use it instead. Pragmatically speaking, if other code relies on the return type being correct, then naively changing it will break your build anyway, unless you also change the dependent code - but then, if you do that, you probably know exactly what you're doing. But then, writing such a test is trivial, so the only reason for not testing would be that you want people to change the return type at will. |
|||
|
|
