Filling the gap between Conception and Unit Test

Question

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 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

Answer 1

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

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.

Answer 2

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.

Answer 3

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.

Answer 4

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.