V běžném chápání, k čemu jsou testy a jak je psát, je přirozené, že napřed napíšeme kus aplikace (např. nějakou servisní třídu), a teprve potom např. k té servisní třídě dopíšeme testovací třídu a k metodám servisní třídy příslušné testovací metody.
Test Driven Development neboli vývoj řízený testy tento "přirozený" postup myšlení a vývoje obrací. Požaduje samozřejmě, abychom měli zadání projektu, funkční analýzu, technickou analýzu, a pak třeba i interface (jména metod a jejich signatury) např. k té servisní třídě, ale zatím žádnou konkrétní implementaci. Víme pouze, co má daná třída umět, ale nevíme zatím, jak to udělá.
Jakmile máme analytickou část řešení hotovou (včetně interface-u konkrétní výkonné třídy), přidáme tu konkrétní třídu a tzv. "stuby" jejích metod (prázdná těla metod bez implementace, mohou např. pouze vyhazovat výjimku NotImplementedException). Hned potom založíme druhý projekt, který bude ten aplikační projekt testovat.
V testovacím projektu budou unit testy odpovídající metodám z interface-u výkonné třídy, kterou chceme testovat. Přestože zatím nemáme ani řádek kódu, který řeší nějaký use case v zadaném projektu, musíme vývoji testů věnovat náležitou péči, jako by i samotné testy byly součástí aplikace. Pokud je ve výkonné třídě metoda, která se podle např. parametrů chová v různých situacích různě, může být vhodné pro takovou metodu napsat i více testovacích metod, aby pokryly všechny možné scénaře.
Jakmile máme unit testy napsané, můžeme spustit celou jejich sadu (tzv. test fixture). Napoprvé (dokud jsme ještě vůbec nezačali s implementací té konkrétní testované třídy) dopadnou všechny testy "červeně" (fail).
Teprve nyní je čas začít implementovat jednotlivé metody výkonné třídy. Vždy po nějakém uzavřeném úseku vývoje znovu spustíme testy. Toto iterativně opakujeme a pozorujeme, jak postupně stále větší a větší část sady testů přechází z červené do zelené (pass).
Výše uvedeným postupem jsme si vyzkoušeli programování řízené testy.