Martin, On Sat, Mar 21, 2009 at 9:50 PM, Martin Gainty <mgai...@hotmail.com> wrote: > > test driven means if I create a component as a developer I need to install a > JUnit testcase that will test the requisite function >
Actually there's a bit more behind it. Usually, you start to design an application starting with some UseCases, Sequenz-Diagrams, Action-Diagrams, Class-Diagrams etc. So basically you have a MDA (Modell Driven Architecture) reflecting / incooperating *all* business-requirements (hopefully...) When Using TDD, all of that is left behind. The flow of activity is like - analyse the problem / requirement - write a test reflecting the requirement - code something on which the test will not fail As you can see, TDD is more something being used for small projects. I'd even say that what we understand as a project is already too big for pure TDD. TDD is great if you have a small problem, need ti implement a new requirement or just fix a bug / unwanted behaviour. IMHO it's useless for real-world projects having a certain complexity and size. Besides, if you are using something like MDA, you start up like outlined above, however, one you start to implement, you don't start to code but you start to write some tests for the smallest parts aka classes. IMHO tests should mirror the requirements aka modells, however, I do not think that the process should start with tests but tests should come after the design is roughly set. > Rapid Iterative Development means make as small a piece of functionality such > as a component > and then add ancillary functions such as this project requirement The thing is, that we all want the requirements to be complete once we start with the development (which, in my understanding, consists of analyses, design, test, implementation). However, most of us know that requirements almost never are complete. Therefore, one tries to accept the fact and uses something like RID (being developed from RAD). The lifecycle is: - Requirements capture - Analysis - Design - Implementation - Testing After that again starting with requirements capture. This seems to be perfect - but hold it: As you can imagine, it's almost impossible to estimate the effort for a project, since you don't know all requirements beforehand. So the big challange will be to convince your customer that this will not be a fixed-price / fixed-time-project, however, he (the customer) will definately benefit since this approach is most flexiable, you are able to shortly implement new requirements (i.e. market-conditions, new legal requirements etc.). The problem still is: Most customers don't actually know their own requirements, they don't know what they want / need, but still they want a statement on what the project costs and how long it will take... Rgds Gregor -- just because your paranoid, doesn't mean they're not after you... gpgp-fp: 79A84FA526807026795E4209D3B3FE028B3170B2 gpgp-key available @ http://pgpkeys.pca.dfn.de:11371 --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
