Create a trading application in Java – Task : Define the development methodology (5)

Incremental development

The application development will be divided in several steps.
In order to prevent the tunnel effect (we build a lot and we have a result only at the end of the development), we will implement one UC at a time and provide at the end of each UC implemented a testable application allowing us to test our feature.
The key idea in an iterative development is extending the application progressively.
So, the first version will cover the first UC, the second version wil cover the first and the second UC, etc…and so, the last UC will cover all features.
Each UC will be handled in its own wordpress article and the code of the growing application will be provided on github.

Unit Testing and TDD approach

Unit testing is important to validate a development and prevents or at worst limits regressions.
So, we will do it for each UC. We will not necessarily test everything because some classes don’t deserve unit tests because they don’t contain real logic or processing.
I will do tests in first intention (Test drive development) but doing it in an iterative way may demands multiple steps (fail-> success->refactor-> success->refactor->sucess), so i will directly present the final class testing.

Important : before to begin tests implementation, it’s interesting to identify and model our main user story for this use case.
For me, TDD doesn’t mean : no design and no thinking.
Personally, I think that a good TDD approach must mix raw design and test-acceptance approach. The design will progressively be enriched as tests and implementations progess but it should have a minimum basis for starting.
In order to sketch the raw design, I usually rely on the main user story for the handled usecase. Relying on the main user story allows me to identify main message flows and main participating classes and actors.
When the raw design is done for the main user story, I can begin the unit test and the implementation.
Then, for other user stories of our use case, if any, I could address them directly with a TDD approach and refine the design iteratively when needed.

Design raw business classes

As said in the previous paragraph, TDD doesn’t mean : development with no analysis. So, before to begin the development of our use cases, we will first build a raw business class diagram.
This raw business diagram allow to identify more precisely needed classes, properties and relations between classes.
We will of course refined them when the UC implementation will progress.

Projects hosted on GitHub

 

Master branch:
https://github.com/ebundy/jfreechart-bootstrap

 

Ce contenu a été publié dans Non classé, trading. Vous pouvez le mettre en favoris avec ce permalien.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *