Author Topic: Testdriven development - example ?  (Read 420 times)

JohnDoe

  • EA User
  • **
  • Posts: 191
  • Karma: +0/-0
  • EA rocks !
    • View Profile
Testdriven development - example ?
« on: May 05, 2007, 02:21:18 am »
Hello,
is there an example or a tutorial about using Sparxsystems for testdriven software development ?

Based on extremeProgramming philosophy, requirements and tests should be written before the coding of classes and methods begins, which means: Requirements and Tests first, class design later. I would like to see how someone sets up a simple metapher and initial XP construct, then gathering requirements, moving forward to testcases and then implementing what's needed - instead of creating complex theoretical class models, which get obsolete when the programmer starts coding and refactoring.

Is there an example evailable demonstrating EA's features going the XP way ?

Regards
Bernd
« Last Edit: May 05, 2007, 08:12:34 am by BerndWill »

jaimeglz

  • EA User
  • **
  • Posts: 164
  • Karma: +0/-0
    • View Profile
Re: Testdriven development - example ?
« Reply #1 on: May 14, 2007, 04:21:20 pm »
Hi Bernd,

What I am about to describe is not precisely extremeProgramming, but it is the most natural way (that I see, at least) of aproximating it in EA:

Create a use case for every story you would create in extremeProg. (Since your model is extremeProg and not the Unified Process, don't worry about how to relate your use cases with <<extend>> or other relationships.) You can create packages and/or diagram to group your stories, in order to set priorities.

Write your stories in the Scenario tab of your use cases. In order to keep a single place of change, from that point on use the use cases (either in the model, or in a printout) instead of cards.

Display the diagram with the use case/stories you want, then View -> Testing (or Alt+3), and clic on the use case/story you want to design the test for. Right-click on one of the Test lines of the Test Cases dialog, then use the option to copy the scenario to the Unit (or Integration, System, etc.) test. Use the description tab to further describe the test (if needed), and the Input tab to specifiy your battery of inputs.

Of course, a class model would greatly help you to identify the fields you would use for your inputs, but you can model your classes (or not model them) as you prefer. IMHO, what is important is that the use cases, not the classes, are the containers of the stories, and the ones you are going to play out in your testing.

Hope it helps,

jaimeglz