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