0

I'm looking for an update .net 4.5 WPF+MVVM+TDD tutorial for my team.

I have found only one good tutorial

https://deltaengine.fogbugz.com/?W199

My goal is to learn Test Driven Development using WPF and MVVM (we know WPF and MVVM and also use Nunit for unit testing and coded UI)

However I think we can save a lot of time with practicing TDD. Our system contains WPF/MVVM/C# with c++/CLI and C++.

Do you think TDD will reduce the time being spent of bug fixing ?

Improve this question
3
  • 1
    Once you get the hang of writing robust tests instead of brittle ones, TDD is pretty much guaranteed to reduce future bugfixing time, in exchange for requiring more time upfront to write tests, make the code testable, and set things up so the tests get automatically run on every new commit to master and you get emailed if they fail. Usually it's a net positive, if only because nasty surprises later tend to be more harmful than deliberate delays early on.
    – Ixrec
    Jul 10, 2015 at 22:57
  • But tutorial recommendations are off-topic, so voting to close. Better to ask Google or some miscellaneous forums for that.
    – Ixrec
    Jul 10, 2015 at 22:57
  • @lxrec I have removed the question about recommandation
    – Gilad
    Jul 10, 2015 at 22:59

1 Answer 1

Reset to default
5

The point of TDD from a business perspective is really not so much reducing bug-fixing time. You do reduce the maintenance effort, but you spend more time fixing defects while you write the code in the first place, because you never get things entirely correct on the first try (if you could, you wouldn't testing at all). Sometimes one effect predominates, sometimes the other.

However, TDD is still worthwhile because shifting effort upfront makes your process cheaper. The earlier you catch an error, the cheaper it is to fix. It you catch it while it's in your head, you haven't wasted time writing it. If you catch it before you check in, you don't waste time reverting the commit. If you catch it before QA gets their hands on it, you haven't wasted their time. (If you don't catch it until it's live with a customer, fixing it becomes horrifically expensive because you've wasted their time, the time of the support staff, and your own time that could have been used for improving the code base.)

In my opinion, test-driven workflows don't so much reduce errors as shift the occurrence of errors from more expensive to less expensive places in the development process. And that has enough business value to justify turning your way of doing things around.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.