Real World Ruby Testing

At GoGaRuco (Golden Gate RubyConf) today in San Francisco, CA…

Rein Henrichs’ talk:

Testing Frameworks:

Test::Unit
RSpec
Shoulda
Mintest
Micronaut
Bacon

RSPec (BDD Framework)

Shoulda (BDD Framework for Test::Unit)

Minitest (Replaces Test::Unit in 1.9, BDD syntax, it’s very fast)

Micronaut (Light-weight BDD framework, API compatible with RSpec)

Bacon (very lightweight RSpec clone, around 350 lines of code, runs very fast)

Baretest (BDD style framework, has a lot of formatters, has a concept of a ‘suite’. In a suite, you can declare dependencies)

Riot (No setup or teardown blocks, setup defines a “topic”, Like RSpec’s subject block)

——

How do you choose a Testing Framework:

  1. Familiarity
  2. Expressiveness (how much feedback the tests give you about your system
  3. It doesn’t matter too much which framework you use as long as their is a good community around it.

Why we test and how we test:

  • Confidence
  • Communication
  • Teams relax and develop trust – they will have greatest expectations that things will work.
  • Customers learn to look forward to releases

Why Do We Test:

  • Drive Development
  • Manage Change

Good Test:

  • Fast Focused Feedback
  • Slow tests won’t get run enough
  • Each test should test only one thing at a time
  • Localize problems quickly
  • Minimize distance between test and code

Common Problems in Tests:

  • State leak – when order of tests matter, that’s an issue. Make sure tests are encapsulated. The state should be a known state at the beginning of each test. Where is my shared state and what’s changing that state?
  • Long setup code – it means that your code probably needs to be refactored.
  • Setup duplication – If you have the same setup block repeated in multiple places. These things may be pointing out design problems in your code
  • Long Running Tests – The shorter the feedback cycles, the more tests will be run and the more times they are run. Long running tests don’t get run enough. They also may be indicating design problems
  • Fragile tests – don’t wait to fix fragile tests. These can make a lot of developers frustrated more than anything else.

Write simple tests. If you can’t write simple tests, it probably means that you have a design problem.

VN:F [1.9.22_1171]
Rating: 0.0/5 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)
Facebook Twitter Email

Leave a Reply