There is substantial overhead when doing TDD, but the code is better for it and the knowledge transfer is automatic.
Doing things right takes time and a lot of effort.
What I found was my story bullets, what I call Acceptance Tests, were not completely thought out. It's hard to anticipate what you will be testing until you really spend some time focusing on the feature, which includes how the user will use the system, which in turn means views. Because we were unsure of the acceptance tests we started with wire-framing the two views (ForgotPassword & ResetPassword). Then psudo-coded our implementation in the form of comments so we generally know which services would need to be created. Then at the back-end it was a return to TDD to build our services. Eventually this brought us back up front where we tested our controller actions with mocks of these new service(s). It went pretty well I think, but led me to wonder about a few things.
First, most TDD tutorials only test business rules at the domain level (back end). When in reality we are developing our solution in an all inclusive way. Our features, to be complete need a front to back, or back to front (however you decide) implementation. I'm not saying I want to write a bunch of implementation tests, but we have to be looking at a workflow that covers all these pieces and interaction between these pieces, and I don't think we are there yet.
In the real world, is it possible for the business to write valid acceptance tests that we could convert directly to test methods? How does this work where your features are coming from the business who on one extreme wants to design and architect the entire solution, or on the other extreme doesn't have a clue what he/she wants. I think what we realized is that we developers will almost always end up massaging the acceptance tests while we determine more exact requirements.
No comments:
Post a Comment