Test Driven Development (TDD) is a code writing approach when the developers first write a test based on the specification and then write the code. This is just the opposite that the developer community got used to. The conventional approach that we followed was to write the code and then write tests for it. To be honest, the real practice many times was to write the code and test it with ad-hoc tests and no unit tests at all. Being a professional, you will never do that, by the way. You always write tests. (And now, write it down a hundred times: I will always write tests.)
One of the advantages of TDD is that the tests do not depend on the code. As the code does not exist at the creation of the test, developers cannot rely on the implementation of the unit and, thus, it cannot influence the test creation process. This is generally good. Unit tests should be black box tests as much as possible.
A white box test depends on the internal working of the system tested. When the code changes the white box test, the code may also need tuning to follow the change. The advantage of a white box test can be the simpler test code. Not always.
Gray box test is a mixture of the two.
Unit tests should be black box tests, but, many times, it is not simple to write a black box test. Developers will write a test that they think is black box, but many times, this belief proves to be false. When the implementation changes, something is refactored and the test does not work anymore and it needs to be corrected. It just happens that knowing the implementation, the developers, especially those who wrote the unit, will write a test that depends on the internal working of the code. Writing the test before the code is a tool to prevent this. If there is no code, you cannot depend on it.
TDD also says that the development should be an iterative approach. You write only one test at the start. If you run, it fails. Of course it fails! As there is no code yet, it has to fail. Then, you will write the code that fulfills this test. Nothing more, only the code that makes this test pass. Then, you will go on writing a new test for another part of the specification. You will run it and it fails. This proves that the new test does test something that was not developed yet. Then, you will develop the code to satisfy the new test and, possibly, you will also modify a block of code that you have already written in the previous iterations. When the code is ready, the tests will pass.
Many times, developers are reluctant to modify the code. This is because they are afraid of breaking something that was already working. When you follow TDD, you should not, and at the same time, you need not be afraid of this. There are tests for all features that were already developed. If some of the code modification breaks some functionality, the tests will immediately signal the error. The key is that you run the tests as often as possible when the code is modified.