Fast, Sexy, and Svelte: Our Kind of Rails Testing

Get Started. It's Free
or sign up with your email address
Rocket clouds
Fast, Sexy, and Svelte: Our Kind of Rails Testing by Mind Map: Fast, Sexy, and Svelte: Our Kind of Rails Testing

1. speakers

1.1. Dan Manges (ThoughtWorks)

1.2. Zak Tamsen (ThoughtWorks)

2. spectrum

2.1. unit

2.1.1. what is?

2.1.1.1. finegrained and focus

2.1.1.2. one object at a time

2.1.1.3. fast!!

2.1.2. avoid unit test brittleness

2.1.2.1. activerecord test -> hit the database

2.1.2.2. remove db from the equation

2.1.2.3. gem install unit_record

2.1.2.3.1. ActiveRecord::Base.disconnect!

2.1.3. unit test are for any class (not only models)

2.1.3.1. controllers

2.1.3.1.1. using mocks to avoid dependencies of the model

2.1.3.1.2. gem install unit_controller

2.1.3.2. views

2.1.3.2.1. brittle! don't do it

2.1.3.2.2. in the view shouldnt be interesting logic

2.1.4. new way

2.1.4.1. unit test for any class

2.1.4.2. no fixtures

2.1.4.3. not hitting the db

2.2. functional

2.2.1. less fine grained

2.2.2. still fast

2.2.3. hits the db

2.2.3.1. test sql

2.2.4. requires data

2.2.4.1. problems with fixtures

2.2.4.1.1. pain maintaining

2.2.4.1.2. arbirtrary use by different devs

2.2.4.2. model factory (Factory Method Pattern)

2.2.5. for any class

2.2.5.1. models

2.2.5.2. interaction between controller and view

2.2.6. speed

2.2.6.1. slower

2.2.6.2. in parallel faster (33%)

2.2.6.2.1. deepTest

2.3. integration

2.3.1. classic integration tests

2.3.2. sometimes useful for special purpose tests

2.3.2.1. performance tests

2.3.2.2. smoke tests

2.3.2.3. tests simulating multiple users

2.4. --denial--

2.5. acceptance

2.5.1. coarse grained test

2.5.2. selenium

2.5.3. very slow!

2.5.4. writting acceptance tests

2.5.4.1. encapsulating a page

2.5.5. acceptance test

2.5.6. data access

2.5.6.1. focused acceptance test

2.5.6.1.1. hacking cookies to avoid login page

2.5.7. acceptance test parallelization