Ok, so I am a fresh .net developer, I did some in college, but came out of college doing Coldfusion work and now have switched over to a new project in MVC3, using TDD, EF, the whole nine yards.
I am trying to wrap my head around one issue with TDD.
First off, as I understand it, TDD is more of a “Design Practice” than it is an actual way of just merely writing unit tests before code?
Mostly I am confused about how Unit Testing and TDD coexist.
Are my TDD Tests actually Unit Tests, or are my TDD Tests just a way to assist in my designs and then I still use Unit Tests to cover the code?
Anyone have any thoughts?
TDD tests are often (but not always) unit tests. Examples on non-unit tests may be UI tests using WaitiN. The simplest way of thinking about TDD is to think of it as a discipline of ensuring that as many of your requirements (both business and technical requirements) as possible are expressed programatically, so that you can consistently and regularly apply them to your codebase to ensure that you are still meeting the req’s as you make changes.
In practice, this tends to result in different (some would argue better) patterns in your architecture, usually towards decoupling to allow modules to be tested in isolation. In more rigorous TDD environments, it is not uncommon to develop your test first (so that it fails), and then develop your code to satisfy your test. This discipline ensures that your tests fully express the intent of your requirements.