3 ms·

> even private ones. You don't test private API, that's why they are declared private, it makes absolutely no sense to test private members. Now the use of th

by camus2 9y ago

> even private ones. You don't test private API, that's why they are declared private, it makes absolutely no sense to test private members. Now the use of the private member might lead to a different code path : it has to be tested. Unit Testing : test one unit ( a class for instance ) in isolation, which means all collaborators (the classes the tested class depends on) have to be stubbed or mocked. Functional Testing : test multiple unit at the same time to check the behavior of an entire functionality, that's why it is called functional testing. Stub the IO. End-to-end testing: Test the entire system with the IO.

bpicolo 9y ago
> it makes absolutely no sense to test private members Don't agree. I think this is something that people tell themselves to justify the anti-pattern that is private members being nearly impossible to test directly in a variety of languages, but it seems like nonsense. I've never seen a real case for excluding private methods as a testable unit.
- mdpopescu 9y ago
  > I've never seen a real case for excluding private methods as a testable unit. Here's the reason: We're not writing tests; we're writing SPECIFICATIONS. Private methods are implementation details; they're not part of the specification.
  - bpicolo 9y ago
    That's potentially one philosophy on it, sure. Yet that still doesn't preclude private methods from being an independently testable unit. Implementation details are the meat of the whole thing, and so they seem inherently testworthy. The glue code itself, less so. Thanks for that thought though, definitely something I'll think on :)
    - clay_to_n 9y ago
      You should be able to get the code coverage you need (even if 100%) by testing the public API of any class. If this isn't true, it means you have some private methods you can delete. That's how the unit you're testing is used - through it's public API. The public API is the specification of how it works. By only testing the public API, you allow yourself maximum ability to refactor in the future, while still maximizing code coverage. It means that simple refactoring (inlining methods, for example) won't break tests. More importantly, a failing test means something is wrong that is potentially relied upon elsewhere. If you test private methods, you will get test failures without the public API of the unit having changed at all. Your point about "each function is a unit" is fine, you can justify testing private methods with that - but it's inefficient. If it's not necessary to be in the spec (public API), why have you made it so? You're over-complicating the design by locking yourself into implementation details in places where you don't need to. In my experience I've found that testing private methods directly is a code smell. It shouldn't be necessary.
    - camus2 9y ago
      > That's potentially one philosophy on it, sure. That's not potentially one philosophy, that's the definition of unit testing. > Yet that still doesn't preclude private methods from being an independently testable unit Then these methods ain't private as they break encapsulation. You can't have it both ways. Either a method is private or it isn't. > Implementation details are the meat of the whole thing But unit testing isn't about testing implementation details, it's about testing a specification that your API must respect, because that's the behavior collaborators consuming that API rely on. If your collaborators can call a private API then that API isn't private at first place.

by camus2 9y ago

bpicolo 9y ago

> it makes absolutely no sense to test private members Don't agree. I think this is something that people tell themselves to justify the anti-pattern that is private members being nearly impossible to test directly in a variety of languages, but it seems like nonsense. I've never seen a real case for excluding private methods as a testable unit.

mdpopescu 9y ago
> I've never seen a real case for excluding private methods as a testable unit. Here's the reason: We're not writing tests; we're writing SPECIFICATIONS. Private methods are implementation details; they're not part of the specification.
- bpicolo 9y ago
  That's potentially one philosophy on it, sure. Yet that still doesn't preclude private methods from being an independently testable unit. Implementation details are the meat of the whole thing, and so they seem inherently testworthy. The glue code itself, less so. Thanks for that thought though, definitely something I'll think on :)
  - clay_to_n 9y ago
    You should be able to get the code coverage you need (even if 100%) by testing the public API of any class. If this isn't true, it means you have some private methods you can delete. That's how the unit you're testing is used - through it's public API. The public API is the specification of how it works. By only testing the public API, you allow yourself maximum ability to refactor in the future, while still maximizing code coverage. It means that simple refactoring (inlining methods, for example) won't break tests. More importantly, a failing test means something is wrong that is potentially relied upon elsewhere. If you test private methods, you will get test failures without the public API of the unit having changed at all. Your point about "each function is a unit" is fine, you can justify testing private methods with that - but it's inefficient. If it's not necessary to be in the spec (public API), why have you made it so? You're over-complicating the design by locking yourself into implementation details in places where you don't need to. In my experience I've found that testing private methods directly is a code smell. It shouldn't be necessary.
  - camus2 9y ago
    > That's potentially one philosophy on it, sure. That's not potentially one philosophy, that's the definition of unit testing. > Yet that still doesn't preclude private methods from being an independently testable unit Then these methods ain't private as they break encapsulation. You can't have it both ways. Either a method is private or it isn't. > Implementation details are the meat of the whole thing But unit testing isn't about testing implementation details, it's about testing a specification that your API must respect, because that's the behavior collaborators consuming that API rely on. If your collaborators can call a private API then that API isn't private at first place.