In my understanding, design specifications help to formulate unit test cases which make use of internal knowledge (white-box techniques), while if we only have functional requirements, the black-box techniques are more suited.
What happens if we don't have design specifications, and the requirements are often vague or do not have defined boundaries? How will it affect the unit test process? And how do you compensate for it? Do you use your experience, or a specific practice/technique, to fill in the gaps?
Would developing first the functionality be better suited? As you keep developing and gain more knowledge of how it works internally, you can at some point use either white or black-box techniques. You use your previous experience on similar situations to complete the functionality, which means you may have as well written the functional requirement yourself. At this point, do you go for white-box? black-box? Or it depends on the risk/importance of the new functionality?
I'll guess that you're talking about TDD
Would developing first the functionality be better suited? As you keep developing and gain more knowledge of how it works internally, you can at some point use either white or black-box techniques.
or it'll be difficult to create unit tests for functionality that is missing. If we assume that their main idea is to exercise the
the smallest testable part of an application
and mainly are created by the developers. If the case is
don't have design specifications, and the requirements are often vague or do not have defined boundaries
than the code design and implementation are very likely to be with the same characteristics. And the unit tests wont be so much of a help. IMHO it's crucial to know what are building before testing it, even for TDD.