Hi all,
I've been using FDD for some time and it has worked for me (I'm not using it currently due to some organization constraints).
The question I have is regarding testing. Within the scope of BBF there is a milestone dedicated to testing before promote to build. Unit testing seams to be an ideal fit to this. The problem I have is that for integration testing this "slot" seams inadequate. I would like to know how other have fit Integration Testing into this methodology.
Best regards,
Nuno Lopes
Integration and Unit Tests
Nuno,
I have always treated unit testing as part of the class creation process (whether following test-driven development methods or not). The class is complete when it does what is required and passes the unit tests for it.
Integration testing then becomes part of the Promote to Build cycle - ensuring the new class fits into and works with the existing code in the build.
Kind Regards,
Derek Graham
Integration and Unit Tests
Thanks Derek, that is more or less what I thought. The problem I have here is that no one is using unit tests.
May I ask what weight you put into promote to build?
Thanks for the clarification.
Nuno Lopes
Integration and Unit Tests
Nuno,
We're using Draco.NET as part of a CI strategy at the moment so there's quite a bit of weight put on not checking in code which will break the build. The shame, disapproval of your peers and villagers with pitchforks and flaming torches running you out of town:)
Are you looking to encourage unit testing into your development process by requiring it as part of "Promote to Build"?
Cheers,
Derek Graham.
Integration and Unit Tests
Derek,
We are using CruiseControl for automatic build. Unfotunately the build process does not run unit tests becouse there are none :)
Derek :"Are you looking to encourage unit testing into your development process by requiring it as part of "Promote to Build"?"
Oh yes. People are familiar with TDD etc et al. But in order to enforce unit tests I need to actually show that it speeds up development, or at leat does not introduce delays. Do you have any data regarding this? I mean, real values not just forthcoming benefits.
Best regards
Nuno Lopes
Unit Tests
Nuno,
No, I'm sorry we haven't collected any data on unit tests and their effectiveness. I guess the only way you would be able to do that is to develop the same piece of software in parallel teams, one doing TDD, the other not. The problem is that it does make the development time longer for an individual class (say) but the payoff comes in saving on rework down the line. So, observing two teams and all other things being equal, the non-TDD team will probably finish first. What you do have to look at though is the long term development, where oftentimes revisiting the code to fix defects does not "count" in management's view of efficiency.
"There's never time to do it right, but there's always time to do it over."
From my own experience, I have no doubt that the actual development time is reduced and quality is improved using TDD.
Another way to sneak TDD in is in finding bugs after code has gone into a build. Asking the questions "How could I have found this bug before my customer?" and "How can I stop this recurring?" can help to make TDD or the concept of unit tests more attractive.
Again, I have no hard data to support this, just gut feelings from times when I've been part of teams which used or didn't use unit tests.
Kind Regards,
Derek Graham
TDD Discussed Before
TDD discussed here
Thank you all for the replies.
Thank you all for the replies. I guess I've not been following the info posted on this site lately. Need to browse the site and recap some themes.
Best regards,
Nuno Lopes
True cause and effect
It's great when something improves the way we were doing things. This is always good. I think we can sometimes be more introspective with cause and effect. I once heard someone say they thought pair programming was great. I knew this person wasn't a career programmer so I asked him why he thought that way. He replied that he sat beside a great programmer for 2-3 days once and he really learned a lot in that time.
Terrific! I call that mentoring. But you can't go from that single exerience to pair programming as a practice that scales for all or most projects. At the project level, there are a great many other factors in play.
TDD is similarly seductive sometimes because to program something you have to think about it. Thus, it forces you to think. You have the exact same effect by programming anyway but the psychology, the mental model, is different. You don't consider coding the test program as programming (although you should, because that's what it is) and also, you see it as a step before programming. i.e. thinking before programming is good.
Congrats! this has been known for ages - thinking before programming is good. Now, what we should be considering is what is a better way to do the steps before programming? (rhetorical) Rather than substituting programming itself for the pre-programming steps and where we badge-engineer that programming to be something else (such as TDD calling it a design activity).
Jeff
Yes.
I reduced TDD to unit testing, that is for every function write a test function or functions. It is rather difficult to enforce tests to be written before the actual function as I believe it is enforcing too much (it can be an advice). Any function written in code is there becouse it was designed to be there. Wether there is a formal design step in it (as FDD enforces) is not new to TDD.
Yes!
^^^Nuno Lopes
badge-engineering
More badge-enginerring here http://www.realityinteractive.com/rgrzywinski/archives/000183.html
Unit Testing
You may wish to look at Agitar for helping with your unit testing as it automates a whole lot of it.
unit testing is already a required step
The process description for the "Build by Feature" step requires unit testing to be completed before this step is considered complete. I don't think the process mandates when it should be done, i.e. before or after code inspection, but it is part of the verification that the BBF step is done.
FDD doesn't specify particular testing techniques (only that you should do unit testing).
Since the sequence is not specified, in theory you could use a TDD approach. Personally I think TDD is wrong.
Paul.
Depends on definition
Hi Nuno,
yes BBF has a required task called Unit Test but if you read the task description for it, it actually describes more than class-based testing (which is what unit testing has come to mean to many).
There's (at least) three levels of testing that can be in play here. There's class-based testing which we could call unit testing today. There's feature-level testing which is what the task description in BBF is talking about; now there's no good consenus name for this but it could be called dev test, it could be called string test. Finally, there is testing the feature against other features or other parts of the build which we could call integration testing.
All of this is actually in play at this stage and is what was intended by the BBF process (as it's what I've always done on my projects). Looking back at the BBF process description now, I can see it needs clarification and elaboration on this point. I feel the task description should say more (be more explicit) and even though testing is the verification in BBF, it probably should also be explicitly mentioned in the exit criteria.
Jeff
Thank you
Thank you for this excellent clarification Jeff. I was unconfortably thinking that the question I made in the first place was a wee bit "silly" after what I've experienced and read about FDD.
Excerpt from the book about FDD within the scope of BBF:
Task: Unit Test
"Each class owner tests their code to ensure that all requirements on their classes forthe feature(s) in the work is satisfied. The CP determines what, if any, feature team.level unit testing is required ë - in other words, what testing across classes developed for the feature(s) is required.
Task: Promote to the build
"Classes can be promoted to the build only after successfull code inspection and unit test. The CP is the integration point for the entire feature(s) .....
Currently in our organization we are using a Build Server. As integration test can be executed during BBF within the scope of "class integration", systems integration can only be achieved after the build. This is becouse integration testers work only with "stable" builds and try to break them. Builds are generate every two days.
Considering that all can fit within BBF. In which milestones should consider this effort? Code ot Promote to Build?
Best regards,
Nuno Lopes
Terminology
Hi Nuno,
I still think we're stumbling over terminology - i.e. what each of these different tests are called.
The feature milestones intentionally don't include unit test (or any other kind) as for the tracking to work the milestones must be strictly sequential. This is sometimes misunderstood to mean that testing is not important - which is ridiculous as testing is a REQUIRED step in BBF.
Anyway, the reason for the lack of a milestone is that I did not want to prescribe where testing was done (i.e. in what sequence - before the inspection, after the inspection, or overlappiing the inspection). Thus the other purpose of the Promote To Build milestone is to capture the latency for unit test, dev test, string test (whatever you want to call the different testing that's done before the promote to build).
The work your integration testers do that is post promote to build is outside the milestones and the tracking (unless of course, you want to track testing itself using the same FDD approach but as its own project aspect).
Jeff
Excellent!
"the other purpose of the Promote To Build milestone is to capture the latency for"
That was my perception regarding the Promote to Build milestone. But still my case would not have a match. I believe that an article regarding FDD Aspects would be nice as it seams to be a theme ont very well understood. I see the terms here and there used but the scope is not very well defined to be usefull.
I'm currently building a tool that allows one to define process Aspects over a "standard" FDD process, tracking still the overall project progress. This tool will be called FDD Planner and will work with a Tablet PC (Inking). Will support web integration (with Sharepoint), VS.NET integration, Microsoft Office integration and Microsoft Project integration, but this is another story and will take awhile to be come tangible.
My Business Subject for the tool at the moment is exactly FDD Process Management, including activities such as Defining Process Aspects.
Best regards,
Nuno Lopes.
Aspects
Answered here.
interesting
Interesting that you abstract the notion of feature into traceable items. I arrived to the same conclusion while modeling my new tool with the objective to suffice not only FDD needs but possibly other such as writing documentation. For instance in case of documentation we would have a TOC rather then a Feature List. In the case of the new MSF Agile we have scenarios rather then Features.
FDD combines artifacts in a very powerful way. But the the way features are represented (action result object) and the way egathey are tracked its master stuff (milestones/completion weight).
Thanks again Jeff for the clatification.
Best regards,
Nuno Lopes