Discitur Project
I’ve got slept on most nights and worked on it a little. I came across some significant cases. I start from the code that is easier.
1° TDD Cycle (I cleaned all injection code)
the test:
the code:
Simple.
2° TDD Cycle
the test:
the code:
fine.
3° TDD Cycle
the test:
the code:
With this step I created a service to pass initial data into the controller and it works, but this step in app code requires me to update previous test code, cause propertyYData is not injected… that means that the 3° TDD iteration breaks the previous test cases!!! Without a functional reason..
The above example did a little shake my confidence in the TDD in Angular.js , although in the TDD method is a common practice re-engineer the code of the test… even though I would have expected a different behavior (especially in js) .
Then I kept on again, in Angular services TDD. I would like to focus on a detail of this experience . I was making the search service (one of the main service of the application) and I kept applying TDD. In writing the test, shortly after, I came to realize the need to develop the input interface that , in my DDD head( Development- Driven Development ) sounds like that:
where
After several insights (not all immediate as I would expect), I came to the writing of the following test set (the “Dev-Red-Green” usual practice ). I think they are significant:
Remember that my intention was to define the input of my service as an object whose properties could be used as a parameter of REST service. The code that came out was the following
refactored in
With the creation of a service Utility to reuse in the rest of the services.
The question is: was the right choice follow this process?
My answer is quite convinced: NO
Why? Because actually what I wanted to achieve was trivial, It was in my head from the beginning: and TDD is more effective in other contexts ( for me) , or when the algorithms are not so obvious and it is good to point to the logic before write something. Furthermore, to obtain the initial result I have written dozens and dozens of lines of code ( of course, you could probably write better , but my goal was to write tests with some fluency also to be able to compare to a more traditional development ) . I confess that, without TDD, I would have written no code that validates the input, but in the context in which we are, probably NOT needed to write that code. I brought value doing it? Probably yes, but just as likely that the time it takes does not justify that value. I would have brought more value if I had developed directly and I were focused on TDD in other contexts.
An important confirmation . Some days ago I had a pleasant conversation with Lorenzo Massacci , co-founder of E-xtrategy, a local reality, very active in the field of Agile Methodology. Lorenzo told me some experience and his perspective on the TDD and told me: “We are not the “Agile-Talibans”, we use it in the way that best suits our needs. We leave the pure TDD for complex things , for the rest we create unit tests to be automated and let the framework (Angular, consolidated by the experience and the work of others), to take care of many aspects “. I fully agree with Lorenzo ! From my studies and from my readings, I had in mind this conclusion, but hearing that from him, who live the Agile everyday, makes it become something more concrete .
So, to sum up: always think of the final value. TDD JE (Just Enough).
Comments