Znane również jako request specs w kontekście RSpeca, umożliwiają nam zasymulowanie interakcji użytkownika z naszą aplikacją.

• Zaczynając od pisania testów a dopiero później implementując kod, który spełni testy, zwiększamy naszą pewność, że test sprawdza funkcjonalność tego, czego powinien,
• cykl “nieprzechodzący test → implementacja → przechodzący test” powoduje stan przepływu (ang. flow state), dzięki któremu zwiększamy nasze zadowolenie i produktywność,
• testy działają jako klient implementacji, często prowadząć do bardziej eleganckich rozwiązań,
• gdy w ogóle nie wiadomo, jak rozwiązać jakiś problem, czasem lepiej pominąć TDD,
• najpierw piszemy test nieprzechodzący, potem piszemy kod, który przejdzie przez test, a na końcu go refaktorujemy, zmieniając formę kodu, nie zmianiając funkcji (Red, Green, Refactor),

• Testy skupiają się na tym, co powinno się dziać,
• zachęca do używania literackiego języka,
• umożliwia eksport specyfikacji w zrozumiałym formacie,
• specyfikacje powinny być zrozumiałe ekspertom domeny (? - domain experts),
• specyfikacje powinny być uruchamialne,
• powinny wspierać testowanie kodu w izolacji jak i pełnego stosu