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.


What diagrams / exercises / development processes can I insert between "foggy notion of what system is supposed to do" (aka Conception) and "Write Test"?

enter image description here

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.


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.


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.

enter image description here 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.


Some ideas I have explored already that seem helpful (but the question is not about these things):

  • BDD (I used SpecFlow)
  • use case diagrams

SpecFlow 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 Settings"

Here is a picture of what I have tried so far enter image description here


4 Answers 4


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.


You cannot jump directly from "idea" to "implementation". Good example is the "V model" : enter image description here

You start at high level go lower and you write tests on each level. And each level gets more specific in both implementation and testing. For example you write an acceptance test that says that you should be able to add a customer. This results in you writing an integration tests to ensure client can be both created and inserted into database. And this forces you to write unit tests that describe detailed conditions for creating and saving the customer object. And then you implement the code until unit test pass, this will make integration tests pass and that will make acceptance tests pass. So you get few high-level acceptance tests, more integration tests and lots of small and detailed unit tests.

  • Boromir agrees.
    – toddmo
    Mar 20, 2015 at 16:27
  • Sounds like you know your process and you don't get stuck between concept and unit test. Would you mind sketching the flow in terms of tools / artifacts (in the .Net stack if possible). (e.g., "I use accept stories in Accept3000, which automatically create system tests in SuperSystemTesterNet, then for each one I ..., which integrates into NUnit tests")
    – toddmo
    Mar 20, 2015 at 16:35
  • @toddmo I think you are getting into area of "opinion" and "which tool to use" which are both off-topic here. In this case, it is heavily on what fits you and your project. I believe this is not possible without some level of experimentation. Some people are simply able to model the whole thing in their head while others need some kind of tool to help visualize the whole design flow.
    – Euphoric
    Mar 20, 2015 at 17:13
  • are you a .net developer? if i post a question on "software recommendations" will you answer it over there? I'm stuck without ~a way of doing it~. Thanks.
    – toddmo
    Mar 20, 2015 at 19:38

Writing use cases with (say a Product owner) could perhaps get you started. The problem for me is that "conception" in your graph and unit tests are on different conceptual levels. Unit tests are on a very low level (and are best viewed as a code design tool), they do not dictate or guarantee system level features.

I would start by writing automated high level acceptance tests (and you could do that in NUnit if you want to).

EDIT: I think it is hard to say exactly what you should replace ??? in the diagram. If the concept is defined and well know for the developer then she would be able to start writing the unit test directly. Ff the concept is not well defined then I would say "collaboration" (as in: you as a developer need to talk with someone go get more information so that you can write the tests and the code). Perhaps this could be formalized in "create Use cases" - since you need to gather information in order to accomplish that.

For me that kind of process should be separated from the TDD process so perhaps it's best to remove the ??? box - and simply treat the problem "I don't know how this feature works, so I can't build it?" as a different process.

  • Thanks. I didn't mean for conception to be on my graph at all. BTW, I didn't create that flowchart. It was in google image search for "TDD". The small starting circle did not mean conception; it just means "start of flow chart". Did you misunderstand or did I misunderstand what you meant? (I don't understand what you mean by "conception on my graph"). And, when you say "the problem for me" do you mean the problem you have when you do it, or the problem you have with one of my statements?
    – toddmo
    Mar 18, 2015 at 22:42
  • Thanks for your edit. Ok, since this is a solo project done from home while I am unemployed, I am both the customer and the developer. There is no one else to go get clarification from. I did a use case, and that was helpful to get more clear. So you think you can jump right from a Use Case to a Unit Test? That still seems like pretty big jump to me. Use Case doesn't say how it's done, but Unit Tests expects the developer to have already come up with the "How" before starting to write the test. How can I get to know how the feature works, is another way of putting it.
    – toddmo
    Mar 19, 2015 at 17:43

A test fundamentally tells you, "If I supply input X to program P, I get output Y." Test driven development works by writing X and Y first then filling in the gap.

Work backwards. The program will produce some outputs. Whether these are control signals, images, web pages, text, lamps, toast, whatever: outputs. Produce some representative outputs by hand.

There will need to be some sort of data model for the system. This may be as trivial as a single number or a complex set of business objects or a complete numerical model of the atmosphere. This is where people deploy UML, BCNF and so on. You can't avoid reasoning about the data model, but you can relate it to your output examples. "Output X1 is seen when the data model contains D1". So you end up writing a set of output formatters and postprocessors from their tests.

https://softwareengineering.stackexchange.com/questions/244451/relationship-between-tdd-and-software-architecture-design?lq=1 : TDD is a methodology and a means of organising the work of program production. You have to do something first, and in TDD that is write a test. It doesn't absolve you from needing to do architecture.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.