Software Engineering Stack Exchange is a question and answer site for professionals, academics, and students working within the systems development life cycle. It only takes a minute to sign up.
Sign up to join this community
From reading the descriptions, I understand that in TDD tests are done prior to writing the function and in Unit Testing, its done afterwards.
Is this the main difference, or the two terms can't even be compared as such. Perhaps, Unit Testing is an integrated part of TDD.
Unit Testing refers to what you are testing, TDD to when you are testing.
The two are orthogonal.
Unit Testing means, well, testing individual units of behavior. An individual unit of behavior is the smallest possible unit of behavior that can be individually tested in isolation. (I know that those two definitions are circular, but they seem to work out quite well in practice.)
You can write unit tests before you write your code, after you write your code or while you write your code.
TDD means (again, kind of obvious) letting your tests drive your development (and your design). You can do that with unit tests, functional tests and acceptance tests. Usually, you use all three.
The most important part of TDD is the middle D. You let the tests drive you. The tests tell you what to do, what to do next, when you are done. They tell you what the API is going to be, what the design is. (This is important: TDD is not about writing tests first. There are plenty of projects that write tests first but don't practice TDD. Writing tests first is simply a prerequisite for being able to let the tests drive the development.)
You can do unit testing without doing test driven development. However you can't do test driven development without using unit tests.
When you do traditional unit testing, you write test after you wrote your code.
Test driven development approach is to write unit test before writing code.
Most interesting advantages of TDD (IMHO) comparing to simple Unit Testing:
TDD and Unit Testing are two very specific terms which often get misused.
TDD is writing a test which will fail, then writing the minimum amount of code required to make it run, then refactoring the code to make it clean. This is done in cycles, fail -> pass -> refactor, adding a new test for each known requirement for the code. More recently, TDD has become even more specifically about writing unit tests in that cycle, to distinguish it from ATDD (a subset of BDD) which is writing acceptance tests in a similar cycle.
Unit Testing is about testing a code in small, isolated units. The common confusion here is to think that if you're using a unit testing tool, such as xUnit or Rspec, to run tests that you are writing unit tests. This is not necessarily true. Those tools can be used to run say tests using the Selenium framework - in that case you are writing acceptance tests using a unit test runner. Unit tests are very specifically tests which focus on a small piece of logic, isolated from everything else for the sake of speed (so that you can run them often and get fast feedback on new bugs).
TDD is the approach of writing the test cases before development as you said and then the developer writes the code to pass the test cases. Unit Testing is a term used to describe a narrow scoped type of testing other than system testing, integration testing and acceptance testing.
TDD is a philosophical approach to writing code: write the tests first. The tests you write are unit tests.
The way I separate the two is to consider that TDD is less about testing, and more about designing the code. Unit tests are then used to set the expectations for the end code. When the end code is written, and passes tests (specifications), you have code that was designed using tests.
All excellent answers. I would only add that unit testing tends to regard the 'unit' as a small component, while TDD scales up to include integration and acceptance tests.
(Some TDD variants regard the 'unit' as the smallest incremental step towards the desired functionality...)
