1. 1

Just spotted an interesting line in this CppCON talk…

https://github.com/CppCon/CppCon2015/blob/master/Presentations/Lessons%20in%20Sustainability/Lessons%20in%20Sustainabili%E2%80%A6

It has all the usual ideas about increasing automated test coverage… but takes it one large step further.

If our change breaks you and you have no tests, not our fault.

Sadly staff turnover means many lines of code were written by folk no longer here.

So the “whose fault is it” becomes a bit fraught.

A larger interpretation of this rule would be…

Change has priority over Untested code.

Taking the idea to it’s logical conclusion (in our domain)….

Functionality without automated test coverage explicitly becomes “Deprecated” functionality. ie. Expect it to be removed/broken in some future release.

ie. Fair game to be broken / removed if it impedes anyone altering the code for any reason.

ie. If the product owner cares about functionality, he had better make sure it is pinned in place by automated tests.

ie. The Product Owner becomes the champion for prioritizing deficits in automated test coverage over creating new features.

  1.  

  2. 1

    In discussing this with some colleagues I can up with a slightly different formulation…

    The measure of the commercial value of a feature, is the expenditure of real resources to ensure it’s continue existence.

    1. 1

      For some reason your link did not work for me, it was cut off. here

      I’m not sure why you say this is the next big step, I’ve heard these ideas for a long time. I think most of them are used to validate a lack of empathy in breaking a dependent piece of code, this is just another perspective on it. It all sounds nice, but the truth is it’s all artificial . When push comes to shove, the testings are going to be deprioritized, sometimes validly but usually not.

      1. 1

        The various other policies around test (test first, test new code, catch bug first in test) has certainly increased coverage.

        But I have observed that in the presence of legacy code with weak coverage the growth of coverage stalls. Because the incentives on the programmers and the business end are perverse, legacy code continues to grow without matching test coverage.

        I have observed that the functionality in the legacy code often silently breaks…. and this is only discovered when some customer complains a long time after the breakage was introduced.

        Why do I call this a Big step?

        It is only through a rather radical policy such as this, will the next big increase in test coverage occur and/or a big deletion of dead / unused functionality.

        I’d be happy to see either.