Don’t you hate when testing takes 3x as long because your specs are hard to understand? Following a few simple patterns, you can easily take a bloated spec and make it DRY and simple to extend. We will take a bloated sample spec and refactor it to something manageable, readable and conci
Don’t you hate when testing takes 3x as long because your specs are hard to understand? Or when testing conditional permutation leads to a ton of duplication? Following a few simple patterns, you can easily take a bloated spec and make it readable, DRY and simple to extend. We will take a bloated sample spec and refactor it to something manageable, read
This presentation is meant to be a live coding workshop and an in-depth review of test architecture. More often then not, specs become unwieldy and bloated because we forget that RSpec is still Ruby code and should follow a pattern. Starting with a small Ruby (Rails) project with a handful of RSpec tests, we will review the User model and it’s related unit test. This refactor kata will hit on:
Three primary design patterns:
Minimum Valid Object
Start testing from a verifiably valid state; therefore, every mutation of the object is planned and tied to the failure (if there is one).
Using multi-dimensionally areas to visualize the data being tested; making it much simpler to track variations and mutations
Snapshot a string representation of an object to file for later comparison. This works well when there is a lack of existing test coverage and the complexity of the application makes it hard to assert that the state of an object is accurate (green) in the beginning.
Briefly I review a few practices that help keep the tests functioning well:
I’ve given this talk as both a workshop at RailsConf and for RailsRemoteConf