Test Driven Development and Unit Tests in .net

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.

TDD Tests absolutely can be unit tests.

They certainly fall under the definition of a "Unit Test" according to Wikipedia: http://en.wikipedia.org/wiki/Unit_testing

On the surface, TDD tests are very similar to unit tests. This is not surprising, since you use a unit testing framework such as Visual Studio Tests or NUnit to create both types of tests. But there are differences between TDD Tests and Unit Tests.

Like unit tests, TDD tests can be used for regression testing. You can use TDD tests to immediately determine whether a change in code has broken existing application functionality. However, unlike a unit test, a TDD test does not necessarily test one unit of code in isolation.

Like acceptance tests, TDD tests are used to drive the creation of an application. TDD tests work like mini-acceptance tests. You create a TDD test to express the application functionality that needs to be implemented next. However, unlike an acceptance test, a TDD test is not an end-to-end test. A TDD test does not interact with a live database or web server.

See here for the article.

Roy Osherove (author of the Art of Unit Testing) has a decent video on this:

Understanding Test Driven Development

The main difference is that you're creating the tests up-front (indicating what you want your code to do) rather than afterwards (testing what you've already coded). So in theory, your TDD tests should already cover the production code you write. Pure TDD suggests that you shouldn't write a line of new production code unless you have a failing test that requires it. With experience, you can decide how closely you want to stick to that principle.