4 ms·

I was curious about You can’t (without a lot of chicanery) unit test private methods. Why is that? Maybe you can't test them directly but private methods shoul

I was curious about You can’t (without a lot of chicanery) unit test private methods. Why is that? Maybe you can't test them directly but private methods should be executed and thus indirectly testable by public methods. If there is code in private methods that can't be executed by any public method invocation, it's unnecessary code isn't it?

taeric 9y ago
I've had a similar debate. Someone kept trying to exclude some of our data objects from test coverage reports. I agreed we shouldn't bother testing getter/setters. But, those object better be used in other tests we are writing.
- pleasecalllater 9y ago
  As usually: it depends. Sometimes testing getters/setters is a good thing.
  - taeric 9y ago
    My point is when we checked the report, the file was already getting covered. If your tests of the system aren't using the data objects of your system, you have larger problems.
- JustSomeNobody 9y ago
  The typical argument for getters/setters is that there is some logic that should be performed and that's why the fields should not be public. If there's logic, they should be tested. If there's no logic, they should be public fields.
  - taeric 9y ago
    See my sibling response. The files were tested. There just wasn't a "testGetter" method in our tests.
  - twblalock 9y ago
    No, the point of getters and setters is that the interface to get and set fields should be the same whether or not logic is being performed behind the scenes, and the caller should not need to know. Making fields public makes it impossible to add logic in the future without changing other code. That breaks encapsulation and is generally non-idiomatic in languages with getters and setters.
loup-vaillant 9y ago
> private methods should be executed and thus indirectly testable by public methods. Many people would count that as integration tests. Because if you don't call the method directly, it's not a unit test, for some reason. (I guess it depends whether you consider the unit to be the class or the method.) Some of those people will also say that not being able to "unit" test a method is actually a bad thing. I personally don't care much, as long as I can make sure the code works somehow.
- kolme 9y ago
  I would argue that those people are wrong, and defeating the purpose of object oriented programming, by braking a couple of basic principles like encapsulation and abstraction. Also, they are wrong in that they also defeat the whole purpose of unit testing, which is being able to refactor with confidence that there won't be any regressions. If you "unit test" the private implementation details of a class, you'll need to fix the tests every time you want to refactor it. That's an unacceptable tax. Instead, classes should encapsulate and abstract away a problem for you, from the outside, you shouldn't need to know how it works. It should expose a clear interface ideally as loosely coupled to other classes as possible. And this interface is the bit that needs to be unit tested, the "contract" with the outside world.

taeric 9y ago

I've had a similar debate. Someone kept trying to exclude some of our data objects from test coverage reports. I agreed we shouldn't bother testing getter/setters. But, those object better be used in other tests we are writing.

pleasecalllater 9y ago
As usually: it depends. Sometimes testing getters/setters is a good thing.
- taeric 9y ago
  My point is when we checked the report, the file was already getting covered. If your tests of the system aren't using the data objects of your system, you have larger problems.
JustSomeNobody 9y ago
The typical argument for getters/setters is that there is some logic that should be performed and that's why the fields should not be public. If there's logic, they should be tested. If there's no logic, they should be public fields.
- taeric 9y ago
  See my sibling response. The files were tested. There just wasn't a "testGetter" method in our tests.
- twblalock 9y ago
  No, the point of getters and setters is that the interface to get and set fields should be the same whether or not logic is being performed behind the scenes, and the caller should not need to know. Making fields public makes it impossible to add logic in the future without changing other code. That breaks encapsulation and is generally non-idiomatic in languages with getters and setters.

loup-vaillant 9y ago

> private methods should be executed and thus indirectly testable by public methods. Many people would count that as integration tests. Because if you don't call the method directly, it's not a unit test, for some reason. (I guess it depends whether you consider the unit to be the class or the method.) Some of those people will also say that not being able to "unit" test a method is actually a bad thing. I personally don't care much, as long as I can make sure the code works somehow.

kolme 9y ago
I would argue that those people are wrong, and defeating the purpose of object oriented programming, by braking a couple of basic principles like encapsulation and abstraction. Also, they are wrong in that they also defeat the whole purpose of unit testing, which is being able to refactor with confidence that there won't be any regressions. If you "unit test" the private implementation details of a class, you'll need to fix the tests every time you want to refactor it. That's an unacceptable tax. Instead, classes should encapsulate and abstract away a problem for you, from the outside, you shouldn't need to know how it works. It should expose a clear interface ideally as loosely coupled to other classes as possible. And this interface is the bit that needs to be unit tested, the "contract" with the outside world.