The sequence of TDD is loosely based on the following six steps: 

1. Write a test with the result in mind 
2. Run all tests and see whether the new test fails 
3. Write the code
4. Run the test again
5. Make necessary changes if the test fails
6. Repeat

I just follow the guidelines loosely. The TDD process calls for writing the test cases before writing any code, or in our instance, before any components of the network are built. As a matter of personal preference, I always like to see a working version of the working network or code before writing test cases. It gives me a higher level of confidence. I also jump around the levels of testing; sometimes I test a small portion of the network; other times I conduct a system-level end-to-end test, such as a ping or traceroute test.

The point is, I do not believe there is a one-size-fits-all approach when it comes to testing. It depends on personal preference and the scope of the project. This is true for most of the engineers I have worked with. It is a good idea to keep the framework in mind, so we have a working blueprint to follow, but you are the best judge of your style of problem-solving.