Specify Before You Build (It Pays Off)

Test-Driven Development (TDD) starts with imagining the code you wish existed, watching it fail, and then building it piece by piece until it works.

That first step, defining what the code does, is a huge opportunity for you as a non-technical founder to be involved in specifying what the code should actually do. You don’t need to write code to be involved — while there are formal tools developers might use, even clear, structured prose from you can be enough.

What a Specification Actually Looks Like

I’ve been working on a learning management system and added global search to it. The specification to my development team might read similar to:

The user can click in an always-present search field. This will search for any matching content, classes and coursework, they have access to. The results will be displayed and include a direct link to the content.

Here is the (slightly simplified) actual test your developer might write for this specification:

user = create :user
create :lesson, title: "My Lesson"
create :lesson, title: "Other thing"

sign_in user
fill_in "Search", with: "less"
click_on "Search"

assert_css "h1", text: "Search Results"
assert_text "My Lesson"
refute_text "Other thing"
click_on "My Lesson"

Even if you don’t know Ruby, you can almost map the specification directly from the description to the test. This is great because it means you have a clear idea of what you actually want and you will be able to clearly communicate that to your developer.

Clear specs are a great start. But how do you make sure your dev team actually uses them? That’s tomorrow’s topic.