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
release (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
we can see that we did 11 major releases and 19 minor releases during the last
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
PercentageCoverage < 100 AND // not 100% covered by tests and
(CodeWasChanged OR // was refactored or
WasAdded) // was added.