The Author Online Book Forums are Moving

The Author Online Book Forums will soon redirect to Manning's liveBook and liveVideo. All book forum content will migrate to liveBook's discussion forum and all video forum content will migrate to liveVideo. Log in to liveBook or liveVideo with your Manning credentials to join the discussion!

Thank you for your engagement in the AoF over the years! We look forward to offering you a more enhanced forum experience.

jlacar (20) [Avatar] Offline
I find this section quite confusing; the discussion is not coming together for me.

Figure 1.2 shows two "plateaus": lower one is labeled as "The Quality Plateau" and the upper one as "The Lost Potential Plateau." However, in the discussion about the Quality Plateau, you say one of the factors that creates it is "Lost potential of tests as design tool." This is confusing to me; doesn't the figure say that the second plateau was about lost potential?

At the end of Section 1.3.1, you also refer to the second plateau, the one labeled earlier as "The Lost Potential Plateau," as the "plateau of diminishing returns towards a 100% code coverage." I find the multiple names referencing the same thing confusing, just as it can be confusing to read code that refers to the same value/object with different variable names.

In Section 1.3.2 The Lost Potential Plateau, third to the last paragraph. Here, you summarize what needs to be done to get across both plateaus. It's confusing to make this a part of Section 1.3.2 because it recommends to "Start using our tests as a design tool." But "Lost potential of tests as a design tool." was part of Section 1.3.1 The Quality Plateau. I think it would be better if the last three paragraphs in Section 1.3.2 were in a separate section, maybe as Section 1.3.3 Crossing the Two Plateaus.

I am one of those developers who thinks that 100% code coverage is hardly ever necessary. Striving for it is, more often than not, just wasteful. But this statement: "This is the plateau of lost potential... to go beyond this point and continue our journey towards a higher level of productivity..." can be taken to mean that we should try to go past 100% code coverage to be more productive. I don't think this is what you meant but that's how it reads to me.

I think the difficulty I'm having with the "Law of Two Plateaus" idea goes deeper than the disconnected discussion points though. To me, TDD and maintaining the quality of the tests go hand-in-hand. They do not have the lower/upper relationship that you propose but rather, they are two sides of the same coin. It's hard to do TDD if your test code is crappy. So while you're exploring/elaborating your design with TDD, you also need to constantly refactor your test code and keep its quality as high as that of your production code. To me, having tests that guard against regression and incorrect implementation is just a happy side-effect of creating a good design using TDD.

See this: and the Bob Martin quote in 6. Why TDD?

Message was edited by:
jlacar (20) [Avatar] Offline
Re: Section 1.3 Law of Two Plateaus
Ok, so I read this whole section again and here's what I get so far:

- If you don't pay attention to the quality of your test code, you will reach a point where it will become increasingly difficult to add new tests that significantly add any value (measured in terms of productivity) to your development effort.
- If you keep your test code in good condition, you can move beyond(?) the Quality Plateau. Note: I don't really see it as "moving beyond" the QP; moving beyond implies that the QP is still there. Rather, I can accept that refactoring "bad" test code allows you to eliminate the QP. That is, you still have more or less the same number of tests but now they give you more value than before and this makes the slope of the curve steeper at the point where the QP was.

What I still don't get:
- What exactly it is that we're NOT doing that causes us to become stalled on the Lost Potential Plateau