No Significant Threat After All, and an Argument
Turns out there isn’t a threat to the program after all. Mark and Louis are in no real danger of being flopped by the parole board as a result of anything the force working against them can do to them. It’s even fallen into doubt as to whether that force is actually working against them, or simply wounding their egos. They have decided to stay rather than leave. And if Mark and Louis aren’t threatened, the program isn’t either.
Tonight we started off with an interesting argument and finished with a list of definitions.
The argument was about testing only through the front door: that is, working under the self-assumed constraint that your tests must only ever call public methods of the class under test. We examined both the pro position and the con positions:
Pro: No package-private production methods. Tests call only public methods. All non-public methods are private. Class is a black box from the tests’ perspective.
Con: Maybe a few private methods, but mostly either public or package-private. Tests have near-total access to the class under test. Class is a white box from the tests’ perspective.
Arguments for the pro side were:
1. Tests may be more understandable because there’s less mocking involved and the class is being called through its public interface.
2. Changes to the implementation (but not interface) of a class don’t require test changes; also, since they don’t require test changes, the original intent of the class is clear and preserved.
Arguments for the con side were:
1. Tests for indivdual “private” methods are much shorter because they must contain significantly less setup code.
2. There will probably be fewer tests, because to test every code path through the front door means that if the code makes n independent binary decisions, you have to have at least 2^n tests to cover each possible path, while if you’re allowed to test private methods you can do it in 2n tests.
3. Spending extra time writing more numerous and more complex tests so that you can change the implementation more easily in the future qualifies as goldplating, because chances are best that you won’t need to change the implementation in the future.
4. If you do need to change the implementation in the future, you can write characterization tests then, before you change any code.
With some abstentions, the count at the end of the argument was Pros 4, Cons 3.5.
(Yes, yes, there were more than 3.5 cons there because it was a blinkin’ prison. I get it. Ha ha. Shut up.)
I’m going to see if I can get that argument started on Pillar’s Socialcast site.
The list of definitions was of types of tests. We listed integration tests, unit tests, system tests, functional tests, smoke tests, and various other forms, and discussed what each term meant. Sometimes the meanings were different for different folks.
Great discussion. Hope to do it again next week.
Soon, though, the Lifeline lab should be back open, and we’ll be able to actually sit at machines and code again.