I am stuck trying to do TDD. I'd rather seek the counsel of others who have gone before rather than waste time with trial and error. QUESTION:What diagrams / exercises / development processes can I insert between foggy notion of what system is supposed to do (aka Conception) and Write Test?Anything else included in this question is simply additional information to help communicate / clarify my question; not to change the question in any way. I do not care what diagrams / exercises / development processes I use, as long as they get me unstuck.When I say Conception I just mean a foggy informal mental-only notion of what a system should / can / will / might do.FORM OF ANSWER:I'm trying to navigate from conception to Unit Test in my development process. I'm looking for a way, a path, a road map, a bridge. An answer might look something like this:do a xyxyx type diagram to get the aaaas, then take all the  aaaas and do a wywywyw diagram, then all the ccccs on the  wywywyw diagram will be the classes you need to unit test and the  lllllls will be the scenarios of the tests.PROBLEM BACKGROUND:I found a TDD flowchart and converted it to a Google Drawing. I'm using NUnit. I have studied TDD, know what it is and practiced it somewhat. This flow chart is for TDD only; no steps before Unit Testing are included.The flowchart starts out with Write Test. I had my concept, nothing I had read said I needed anything else first, so I tried following the flow chart. It was too much of a leap to go from foggy notion to Unit Test. This caused me designer's block. Then I read someone say just do it! I tried that, but the resulting tests and ensuing code wandered somewhat aimlessly since there was nothing to guide what tests to write.ATTEMPTS AT SOLUTION:Some ideas I have explored already that seem helpful (but the question is not about these things):BDD (I used SpecFlow)use case diagramsSpecFlow starts with a verbal description of a feature and creates tests that NUnit can run; they don't look like the unit tests I created manually but maybe I'll figure out how they relate to one another.Use cases helped me get convert the initial foggy notion into a formal description, which was a bit of sunshine. I used Visual Studio 2013 for that. I don't see any facility (in Visual Studio at least) to convert my use case into Unit Tests, although I found some evidence that this is one purpose of a use case. Quoting from the UML User Guide, 2nd ed., p.246:A use case diagram can be forward engineered to form tests for the  element to which it applies.And it looks like Visual Studio maybe wants to convert it because it can store template data on the use case and has Code Generation SettingsHere is a picture of what I have tried so far
Filling the gap between Conception and Unit Test
c#;design;unit testing;tdd
Two things could help you there:Instead of Use Cases, User Stories. Why? Well User Stories are written for/by the user. They are not an accurate description of functionality, but do specify what the user wants to do. This can be your initial road map into writing code that actually allows the user to do something, rather than comply with system specification. A class diagram. Once you understand the functionality you want to code, you have to create the model you'll be using. This doesn't have to be complete, or extensive; the idea is that you'll define your design (and what classes you need) while doing your tests (this is why TDD is 'design'), but you need to know what classes you need, the properties they have, etc. If you're working with small user stories (as they usually are), your class diagram is going to be small. So it is really more that you need the 'idea' of what classes you'll be needing. 