CF SESSIONS



Test Driven Development

Writing Better Code in Less Time


theCloudFactoryHQ




Smart People
Smart Programmers

High Progress 
Without Any Process


NOT A GOOD THING



We know how houses are built.
Just give us some bricks and we'll get started.





PROFESSIONals


★ PROCESS ★


DESIGN, PLAN AND PREPARE FIRST

TDD is a design process, not a testing process


TDD And Us

If I write tests, I may not finish this feature on time.

Don't be this guy


I'll go back and write tests afterwards

Don't be this guy



TEST FIRst !!!


Don't be this guy either


TESTS PROVIDES

  • Documentation of code
  • Catch future errors
  • Long-term time savings

Tests are Tools


Test Driven Development


  • Understand the requirement
  • Decide what the code will do
  • Write a test that will pass if the code does that thing
  • Run the test, see it fail
  • Write the code
  • Run the test, see it pass


TDD PROVIDES


  • Design and plan before we code
  • Document our design
  • Proof that code implements design


Encourage design of Testable code


TESTABLE CODE IS A GOOD CODE


Modular

Decouple Design

Methods of Limited Scope

Reduction in Cyclomatic Complexity 


EASY TO FIND BUGS


EASY TO UNDERSTAND


EASY TO MAINTAIN


EASY TO DEVELOP



TEST DRIVEN DESIGn

FASTER AND BETTER


But ..

It does take a while to learn this 




HOW DO I TDD

Units, Integration, Functional
Integration tests are Scam
Yes, You Should Write Controller Tests!
Don’t use Cucumber unless you live in the magic kingdom of non-programmers-writing-tests 
Don’t aim for 100% coverage
Don’t test standard Active Record associations, validations, or scopes.
You’re probably doing it wrong if testing is taking more than 1/3 of your time. 
A test is not a unit test if it talks to the database,  or touches the file system
Do not test APIs with Capybara. It wasn’t designed for it. 


Make TDD to


  • build your road map
  • guide you
  • optimize



Unit: Do our objects do the right thing, and are they convenient to work with?

Integration: Does our code work against code we can’t change?

Acceptance: Does the whole system work?



Skinny Controller

Fat Models

Fatter Lib Files

No Test Should Repeat

Test may be skipped for exploratory code

TDD In CF

USE-CASE 1:

Interface


Change


Event


Respond


USE-CASE 2:

APIS - REQUEST - RESPONSE



  • Params to accept ( What we receive)
  • Params to send (What we have to return)
  • Status Codes



FEEDBACK

And

DISCUSSIONS