A while back the team and I took part in TDD training, and there is currently a big push for it in the company. In our department there is no distinction between Software Architects and Software Engineers, we all individually see a particular requirement through from initial reporting to test and production.
When I am developing a new feature, I find myself using the process of coding to shape the design. When I find myself wanting to Copy/Paste, I then spot that part of the code as potential duplication, which may cause me to refactor to push that particular bit of logic up into a base class, for example. Or, if I am having to work hard to route a dependency through multiple levels of dependency injection, this highlights a design flaw.
How do I reconcile this with TDD, specifically "writing tests first"? I can't be sure of the end requirements of a class as it may change dramatically from start to finish, and I struggle to justify the extra time in writing tests if I am only to write them again when the design evolves dramatically.
Aucun commentaire:
Enregistrer un commentaire