Ship It Often vs. TDD


Ayende recently answered
the question what the bare minimum aspects
of Agile project would be?
His opinion is: Ship it Often.


Without surprise, most of
developer would instead have answered with TDD. Personally,
I cannot answer this, as I cannot answer if in a good meal the main course is more
important than the dessert.


I wrote about this
subject a year ago in the article How to
avoid regression bugs while adding new features?

Basically, I wanted to underline with this article the empirical facts that:

  • Code that works in
    production will likely continue working properly in the future as long as it is not touched.
  • The vast majority of new defects
    introduced by a new release come from refactored and added code since the last
  • As a consequence, before releasing
    the team should focus its attention on refactored and added code since the last
    (i.e the diff).

This indirectly advocates
for the principle of small iterations and ship it often. The shortest is the
iteration, the smallest is the diff on which to focus on. This is one of the top goal for the development of NDepend. On the release
notes page
we can see that we did 11 major releases and 19 minor releases during the last
24 months.



By focusing our attention
on diff I concretely mean:

  • Code review diff.
  • Smoke test features
    corresponding to diff in code.
  • Write unit tests to ensure
    high coverage on diff.

This is just common sense! At this point, the need for high tests coverage is joining the need for
short iterations. Because when
iterations are short, the amount of fresh code to test is relatively small and this
is the best motivation to actually write tests



NDepend can help both
code reviewing diff, and also ensure high coverage on diff. For code reviewing
diff you can use the build comparison feature coupled with the ability to plug a
source code diff tool to NDepend
. More on leveraging Code Reviews with NDepend can be found in this post.



For ensuring high coverage
on diff you can mix the build comparison feature with the import of test
coverage metrics. I wrote a full blog post on this, Are you sure added and
refactored code is covered by tests?

Basically the idea is to use the following CQL query to ask for changes not properly
covered by tests:


SELECT METHODS WHERE            // Select
methods where

  PercentageCoverage < 100 AND  //  not 100% covered by tests and

  (CodeWasChanged OR            //  was refactored or

   WasAdded)                    //  was added.




This entry was posted in Uncategorized. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • Patrick Smacchia

    Krzysztof, we are in-sync, I also think it is a vital query. Be sure that in the future more flexibility we be added to CQL.

  • Krzysztof Kozmic

    The CQL query at the end of your post is I’d dare to say one of the most important queries of all in the NDepend, in terms of code (as opposed to architecture) quality.
    If I was to have only one query ran by NDepend during my daily build, that would be it.
    Even more, if CQL was supporting subqueries or joins, I’d even expand it to the following:

    SELECT all methods that were changed or added and all methods called by them where coverage <100%

    Anyway, I’m really glad you bring this issue up, because it is very important

  • Ed Kohler

    I love the logic here. It also benefits the business from the perspective of gradual acceptance of new features, easy roll-back of things that prove not valuable in the real world, and easier performance testing of one new feature at a time.