Agile Software Development - Comments

Redmine

Joshua Hoover — Thu, 03 Jul 2008 14:39:16 -0700

I also recommend checking out Redmine, which is like gForge, CollabNet and others. It's relatively simple to use and is under active development.

You cannot automate everything

pbielicki — Thu, 03 Jul 2008 06:29:54 -0700

You should consider code coverage tool as a messenger that tells you what's wrong. Code coverage tool will not cause you problems - it will show existing problems in your projects. And these problems were there before but nobody told you about it :)

How you interpret reports is the other story and is very much up to you and the project. I presented my way of looking at Cobertura reports that helped me in many projects. I don't think any automated tool that will delete unused lines of code is cool here - it could remove some critical parts of your system. You cannot automate some processes - most of the time human will decide what to do with the "red code".

And some responses ;)

2. It sounds slippery ;) Generally everything is possible - the question is what is the value of the framework to do round-trip code generation with full bidirectional synchronization, etc.
3. Yes - you should definitely test your code and check whether your changes broke the original code or not.

One more thing

JSabatier — Thu, 03 Jul 2008 05:25:14 -0700

1. My code is well tested (maybe not well tested but at least I know to what extent it is tested)
If you respect the liskov principle or even more you are using a design by contract (cf B. Meyer), your extended class must pass the mother-class' test.

My point of view ;)

JSabatier — Thu, 03 Jul 2008 04:57:50 -0700

I think article deals with two topics:
> What is the purpose of TDD (Test Driven Development)?
> What is code coverage?

TDD is a part of XP (eXtreme Programming). By doing your test first, you are fixing the interface of your class and doing the technical requirement (In fact you are playing the role of the customer). This helps you to avoid useless code, make your ideas clear about the responsibility of your class, and the dependency of your class (moke etc.). Thus, it’s the best way to be sure that your code is unitary testable.

Code coverage is a metric… of quality? Of Complexity?
The difficulty to cover a code is directly linked by the cyclomatic number. The biggest cyclomatic number you have, the most exhaustive will be your job. So the code coverage is not a metric of complexity, but it helps to reduce this one.
When you have a good coverage, you can avoid some regression thank to your tests. It helps us to reduce the number of bugs, and thus increase the quality of the code. So this is not a metric of quality, but helps to have a better quality.

My conclusion is that the code coverage is mandatory step to provide good code. Don't forget that tests and code are inseparable. When you re-use a code you must re-use the test...

This was my simple but I hope not simplistic point of view ;)

Generate continuously, but not necessarily stop the build

Artem — Thu, 03 Jul 2008 04:15:06 -0700

A pile of documentation is often generated during the CI build. Even though the coverage reports are to be analyzed by people, you still can generate them on the continuous basis as well as generate diffs and send alerts if coverage figure goes down quickly.

1. The application was

groszek — Thu, 03 Jul 2008 04:06:05 -0700

1. The application was tested, but not with the unit tests.
2. It can work, if you do it smart. For example if you have to support some external API, you can define it as XML and generate the code that verifies parameters, prints logs, etc. and then calls the actual function which won't be generated (imagine a bit disabled implementation of aspect programming).
3. You are right, you should only care about your new code and only measure it for code coverage. But sometimes you have to change the legacy code, should you write the tests then?
I think that without integrating with continuous integration the practice will die in face of some time pressure. I was expecting more geeky answer, like use – a tool that deletes the code not covered by the unit tests :).

Re: We were using a code

pbielicki — Thu, 03 Jul 2008 02:53:49 -0700

1. Why should you test something that is already tested? If you copy the source code from the legacy application you should also copy the tests? Why? In case you want to modify copied code.
2. No - it doesn't make sense to test generated code - btw. generated code sucks. Why? Try to modify it and then generate again - guess what will happen to your changes :)
3. I still don't get where you are going to? Why would you test stuff that is provided to you by someone else? If it's a crappy code maybe you should consider rewriting it from scratch but I really don't see any value in testing someone elses code.
4. Absolutely right - 100% code coverage does not tell you anything. 100% code coverage should not be the goal of your project. Use your common-sense.

Generally code coverage does not apply to legacy applications/libraries? Why should you test something that is already in place and is probably tested? If you're using some libraries or 3rd party software you shouldn't test it - you're not provider of this software. If you don't trust it to that extent - don't use it.

If you want to integrate code coverage with continuous integration you shouldn't probably set any threshold. Checking the "red code" manually is NOT out of question. Nobody said you have to check it after each build. Code coverage should HELP you identify dangerous fragments of your code. If you make yourself the prison of code coverage tool it's your problem.

Code coverage tool helped me many times in identifying which parts of my project need more testing and which parts can be removed - our experiences could differ - it's quite natural.

Code coverage applies to YOUR code and the code you are writing now.

We were using a code

groszek — Thu, 03 Jul 2008 02:21:57 -0700

We were using a code coverage tool in a legacy application and encountered the following issues:
1. Some components were reused and well tested in a previous application, where they were taken from, so we didn't want to spend much energy on writing the tests for them.
2. Some code was automatically generated for the debugging purposes, it's a madness to write the tests for it and you can't just delete it, because it is very useful when it comes to debugging.
3. I think that an effort of covering a legacy application with the tests is well described with Parreto curve, even worse - some code is just dead and shouldn't be covered.
4. 100% code coverage still doesn't guarantee that your code will be useful, you still may do the wrong thing right.
Overall the results were blurred by the first two issues, the task was difficult because of #3 and probably doesn't make much sense because of #4.
Your post doesn't show how to interpret the results, only the technical details. If I want to integrate code coverage with continuous integration, when I should fail the build? Checking the "red code" manually each time is out of question.

There are some templates

Artem — Tue, 01 Jul 2008 07:21:08 -0700

There are some templates available. I am going to create video tutorials for them, but not sure when exactly it could happen. Or maybe somebody else could submit them earlier :)

Complex example?

Anonymous — Tue, 01 Jul 2008 07:07:01 -0700

Can you show a complex example? particularly if you need to refactor or there are heavy dependencies?

Tracking progress

hmoeller — Tue, 01 Jul 2008 00:04:33 -0700

@John:

I don't fully agree with you about time tracking. It strongly depends on each individual developer's attitudes whether she finds time tracking useful or rather considers it as kind of spying on her. But if you follow Ilja's hint and use abstract time units (e.g. Story Points) for estimation, you can track progress without spying on your developers. And in the end, this has at least the same effect when it comes to estimating repeating tasks better over time.

What I fully agree about is the importance of historical data, though.

What about tracking your time?

John — Mon, 30 Jun 2008 19:38:29 -0700

Seems like another important component would be tracking your time. The reason is that tracking your time effectively provides you with invaluable data on how long it takes you to accomplish certain tasks. As you continue along in your cycle you will start to see similar tasks repeating themselves and will be better able to slot them into your workday knowing how long they will take. We've been doing this for years and have found ourselves transitioning much easier into agile development as a result. Thanks for the list!

"old list"

Ilja Preuß — Mon, 30 Jun 2008 00:12:08 -0700

Jurgen, thanks for taking the time to think about time management in an Agile context. If the resulting list is also useful for non-Agile projects, all the better!

adding slack

Ilja Preuß — Mon, 30 Jun 2008 00:09:00 -0700

It's true that it's very hard to "correctly" estimate stories/tasks. In my opinion, a better way to solve that problem is by estimating in abstract units of time and using "yesterday's weather" to decide how much can be done in an iteration. Or, if you really need real units of time, use a load factor.

deferring decisions

Ilja Preuß — Mon, 30 Jun 2008 00:05:03 -0700

When deferring decisions, I think it's important to do so *actively* - that is, think about "what do I have to do to be able to further defer this decision?" That's very different from procrastination, and strongly linked to the lean Set Based Decision Making - making a decision that keeps your options open.