Rails Conf 2013 The Magic Tricks of Testing by Sandi Metz

What I wish people had told me about testing: * You write tests in accordance with a pattern: 1. Arrange 2. Act 3. Assert 4. Annihilate If you annihilate your test data with configuration options, and you abstract your "arranging" into factories and custom methods, then every test you write should be exactly three lines. When I learned this it gave me a consistent mental framework to think about how to write good tests. * Test the interface not the implementation: This was an eye opening realization about what to test. If you haven't seen it yet, watch Sandi Metz' incredible RailsConf talk - [VIDEO] - it's so good * Stubs: Stubs are exactly like the viruses' that we learned about in biology class. You load them up with a value then they literally latch onto a method and inject that value into it. When you're just starting out with testing, effective use of stubs can get you really far, and only when you start hitting the limits of practicality is when you need to think about bringing in something more complicated. * Testing isn't easy per se, but it is definitely enjoyable if you focus on making it that way * Cucumber is pretty stupid, don't waste your time with it

Shout out for Sandi Metz book POODR, and her Railsconf talk The Magic Tricks of Testing, if you're a rubyist (though the principles hold true for non-ruby OO programmers too). [VIDEO]

I spend about 30% of my time on a new feature writing tests. BTW that is in RoR which the primary language I code in. I would recommend watching this video by Sandi Matz on testing: [VIDEO] . I have used this methodology a lot to determine what I should test.

There are some really fantastic testing resources in the Ruby community. The talk that most influenced my approach to building unit tests (even though I write Go these days) was one of Jim Weirich’s: [LINK] I’ve found that his zero-knowledge approach gives me a suite of tests that have high signal when they fail. Sandi Metz has also spoken extensively on testing, and I particularly like her advice on using mocks in tests appropriately. This talk of hers on the subject comes to mind: [VIDEO]

Not always before, but always eventually and usually once I’m done with “exploration”. Testing done right should be a time saver in the long run! I think many people are turned off by testing and especially unit testing because it ends up being difficult and maintenance is more of a pain than it’s worth. There are many good strategies to make it easier that in my experience have yet to be well adopted: [VIDEO] [LINK]