Let's say you are working under Scrum and you have a story which very clearly describes, most likely in BDD, what is required as a new feature in the application.

Let's also say that, as a developer you have enough clarity to begin writing your server side code.

Also, you do not know the language, platform, APIs or perhaps, are simply undecided on the specific behaviour of the inner workings of the classes to be built (don't read this as incompetent, just new to the platform, for example).

Given the above, is it appropriate to begin building tests first (TDD) or is it valid to begin working out the logic of what is to be built first, in code.

  • The whole point of "Test Driven Design" is to write the tests first. It sounds like you know the objective. What are you uncertain about? Sep 20, 2017 at 15:03
  • I am, somewhat, trying to be rather declarative (for the stringent SO requirements on posts) for something which is a bit more woolly... Didn't feel I could say something like "you know when you have to write some code and you know what you're going to build but you don't know exactly what it's inputs and outputs are because the story doesn't (and shouldn't) go to that level of detail per (eg) class". In short, I've been given this concern by a colleague and can see their PoV but possibly am having trouble communicating it myself. I'm sure we've all been there though.
    – Matt W
    Sep 20, 2017 at 15:14
  • 2
    How do you have "enough clarity to begin writing your server side code" but are "undecided on the specific behaviour of the inner workings of the classes to be built"? Sounds like a clear contradiction to me.
    – Doc Brown
    Sep 20, 2017 at 15:41
  • Do you know the exact parameters and return types of each method in every class you're going to write when you're writing the BDD scenarios or in the backlog refinement session? - Especially when you're new to a platform. I can know that this, eg, angular component is well within my capability and what structure it will take without knowing - beforehand - every line I'll write.
    – Matt W
    Sep 20, 2017 at 15:43
  • This is also what I was highlighting as a concern in my first comment.
    – Matt W
    Sep 20, 2017 at 15:44

2 Answers 2


The short answer is that test driven development very much supports exploratory testing. If you are learning a language or an API, your very first tests are going to look like baby steps. That's okay.

A test says "when I do this, that should happen". So, write the test with the language feature, and see whether your hypothesis fails. Correct the code or correct the test when you get feedback. Re-factor. Repeat.

You may not want to keep your baby-step tests around for all to see, but that is something to consider later, when you are doing final commits.


The purpose of unit tests is to verify the code unit in question conforms to the requirements. So if you know the requirements of the unit, you can start writing the tests, even before you start writing the code.

If you don't know enough to start writing tests, it indicates the requirement have not been clarified enough, and then you cant really start with the code either. But you state that the story "very clearly describes...what is required", so nothing should be stopping you from writing tests.

  • While I agree that you should know enough to begin coding and if you don't then probably a spike is needed. I disagree that writing the tests after the units of code is TDD.
    – Matt W
    Sep 20, 2017 at 15:57
  • 1
    @MattW: Yes, you write test before the code in TDD. If you know enough to begin coding, then you know enough to write tests beforehand.
    – JacquesB
    Sep 20, 2017 at 16:45

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.