4 ms·

Thanks for sharing, I agree with the points you made. The only thing I would add is that not everything is testable in the sense of given: input, expect: output

by kellros 13y ago

Thanks for sharing, I agree with the points you made. The only thing I would add is that not everything is testable in the sense of given: input, expect: output. A common scenario I encounter is that sometimes when you are refactoring a method and refactoring it into multiple methods (for better readability or segregation); that you are required to make the new (sub) methods publicly available for testing purposes. This goes against the intention of improving readability because now you have to expose certain methods that you would rather haven't be called independently. In such way, TDD helps identify artifacts with too many responsibilities. The best tip I can think of to give someone approaching/doing TTD is to make a check-list beforehand of what you are trying to achieve. This helps to focus your attention on usage patterns and identify 'end-points' (end points being testable artifacts). Just because you're doing TDD, doesn't mean you don't have to have a plan to start with.

pauloortins 13y ago
When talking about this common scenario, there are two ways of think. Some people argue that you shouldn't expose private methods only to test them. You should do it through the public method to keep the encapsulation. Others argue that yes, you should expose these methods to make easier to write tests and to identify possible bugs. It depends, we have to analyze each case and choose the advantages and disadvantages.
PaulHoule 13y ago
In Java you don't have to make the methods public, you can just make them default scope. The test cases can see them because they are in the same package but the rest of the system can't.
- prawks 13y ago
  I'd imagine this is similar to "internal" in C#. If so, that still doesn't equate to being private, as other objects can see them within the package/assembly. To the outside world this is fine, of course, however it removes that additional organizational capability within the package.
  - ghswa 13y ago
    Solving this surely requires explicit support for testing at the language level, eg. a "private testable" scope.
lazerwalker 13y ago
I've often found that not being able to test something in a sense of "given: input, expect: output" is a smell that you're taking the wrong approach and that a better factoring for your code exists (this obviously isn't always the case, perhaps the most common exception being testing integration with third-party code).
wildwood 13y ago
There's nothing requiring you to specifically test every function in a class - though, as others have said, you can set the access level to default or protected to have package-level access for tests. Strictly speaking, though, refactoring should never require new tests, unless you're specifically refactoring to increase testability. New tests should be related to specific bugs or feature requests.

by kellros 13y ago

pauloortins 13y ago

When talking about this common scenario, there are two ways of think. Some people argue that you shouldn't expose private methods only to test them. You should do it through the public method to keep the encapsulation. Others argue that yes, you should expose these methods to make easier to write tests and to identify possible bugs. It depends, we have to analyze each case and choose the advantages and disadvantages.

PaulHoule 13y ago

In Java you don't have to make the methods public, you can just make them default scope. The test cases can see them because they are in the same package but the rest of the system can't.

prawks 13y ago
I'd imagine this is similar to "internal" in C#. If so, that still doesn't equate to being private, as other objects can see them within the package/assembly. To the outside world this is fine, of course, however it removes that additional organizational capability within the package.
- ghswa 13y ago
  Solving this surely requires explicit support for testing at the language level, eg. a "private testable" scope.

lazerwalker 13y ago

I've often found that not being able to test something in a sense of "given: input, expect: output" is a smell that you're taking the wrong approach and that a better factoring for your code exists (this obviously isn't always the case, perhaps the most common exception being testing integration with third-party code).

wildwood 13y ago

There's nothing requiring you to specifically test every function in a class - though, as others have said, you can set the access level to default or protected to have package-level access for tests. Strictly speaking, though, refactoring should never require new tests, unless you're specifically refactoring to increase testability. New tests should be related to specific bugs or feature requests.