Image missing
A [wikipedia:RUP] project consists of 4 different phases. The elaboration phase (the second phase in the RUP project lifecycle) is normally done with a small team. One of the important reasons for this is that you want to define the basic form of your architecture. This means you think about concepts, elaborate on them, develop proof of concepts and select the ones that work best for your specific project.
When asked about my point of view about a guideline concerning code coverage, my answer always is: go for 100% code coverage. 100%, unless… Here is why.
When the guideline for code coverage is 80% (not an uncommon guideline) the devil is in the details. Or in the 20% which is not covered to be exact. When a developer ‘only’ needs to cover 80% of his code, you can expect him (or her) to start with the easiest scenario’s, and work his way towards the more difficult scenario’s until the coverage guideline has been met. This way, the scenario’s which are the most difficult to realize as a test aren’t hit. And, more important, the developer didn’t think about the most difficult scenario’s and how to test them. In that case the remaining 20% is completely unknown*. I know several testers and I can assure you: they don’t like that.
Test Driven Development is hot, just like unit testing your software and any other kinds of (automated) testing. And as we all know: sometimes stuff that’s hot is misinterpreted, explained wrong or just simply used in a really bad way. Unfortunately, testing is no exception to this rule…
I ordered some stuff through the internet a week ago. The packet was sent through the Dutch postal service. They have a track and trace website, that shows where your parcel is at that moment, and where it has been. And that website made me realise the postal service is much like a service bus. I’ll compare it to a single service, to emphasise the differences. Let’s have a look, shall we … ?
Last week we had a meeting with our contact at the department that will be maintaining the software we’re going to be developing in our upcoming project. Normally, these kinds of meetings take place in the end of a project, sometimes even under some (release) stress. At least, that was the case for all the previous projects I was involved in at the customer I’m currently at. Most of the time this is because people want to start developing the software instead of thinking about things that are not necessarily their area of expertise.