This practise is also known by many other jargons like Test Driven Development, Test Driven Programming, Test First Design etc.
What is the underlying objective is to let you know that you need to avoid writing a single line of code till you have not written to test it. It is nothing but saying in a broader term that if the requirements are not clear the project will go down the drain. Now take this saying from your QA and apply to coding process. If you doesn't know how to test what you are coding it is actually same as saying I doesn't know what I am coding.
So if you know what you are coding you will be able to write a brief test first. And that will make your coding requirement clear which will enable you to focus on writing only what is needed.
Follow these basic steps
1) Find out what you have to do.
2) Write a UnitTest for the desired new capability. Pick the smallest increment of new capability you can think of.
3) Execute the UnitTest. If it succeeds, you're done; go back to step 1, or if you are completely finished, deliver the project.
4) Fix the immediate problem: maybe it's the fact that you didn't write the new method yet. Maybe the method doesn't quite work. Fix whatever it is. Go back to step 3.
A key aspect of this process: don't try to implement two things at a time, don't try to fix two things at a time. Just do one.
When you get this right, development turns into a very pleasant cycle of testing, seeing a simple thing to fix, fixing it, testing, getting positive feedback all the way.
Guaranteed flow. And you go so fast!
Try it, you'll like it.