Skip to content
0:00 / 0:00

#sandimetz#testing#ruby

Rails Conf 2013 The Magic Tricks of Testing by Sandi Metz

Confreaks

42K subscribers • 84 videos on Hallway • Conference channel

YouTube
  • Recommended by 8 people: 5 on Hacker News, 2 on Lobsters and 1 curated list.
  • A classic. People kept recommending it from 2013 to 2020.
  • Presented by Sandi Metz

Intermediate. Assumes working knowledge.

144K views13 years ago8 recommendations

Tools and practiceSoftware designTestingRubyDesign patterns

Sandi Metz presents a practical framework for writing cheap, stable unit tests by focusing on the public interface rather than implementation details.

Tests are supposed to save us money. How is it, then, that many times they become millstones around our necks, gradually morphing into fragile, breakable things that raise the cost of change? We write too many tests and we test the wrong kinds of things. This talk strips away the veil and offers simple, practical guidelines for choosing what to test and how to test it. Finding the right testing balance isn't magic, it's a magic trick; come and learn the secret of writing stable tests that protect your application at the lowest possible cost. Help us caption & translate this video! amara.org/v/FGa6/

Why it's here

8 people recommend this

What people say. Recommended as an eye-opening explanation of what to test and how to use mocks and stubs effectively to keep tests stable.

AlwaysBCodingon Hacker News • Recommends

On “Testing code is simple”

…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 - link to this 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 prac…

awesome-talkscurated list on GitHubRecommends

Under “Test-Driven Development”

The Magic Tricks of Testing by **Sandi Metz** (Rails Conf 2013) 32:22

richardjordanon Hacker News • Recommends

On “The Failures of "Intro to TDD"”

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). link to this video

matchmike1313on Hacker News • Recommends

On “Ask HN: How much time do you invest in writing tests?”

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: link to this video . I have used this methodology a lot to determine what I should test.

teerayon Hacker News • Recommends

On “Measuring and Improving Your CI/CD Pipelines”

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: link to this video

jakespracheron Hacker News • Recommends

On “Ask HN: Do you write tests before the implementation?”

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: link to this video link

friendlysockon Lobsters • Recommends

The Magic Tricks of Testing

pushcxon Lobsters • Recommends

The Magic Tricks of Testing by Sandi Metz

u/FlockOnFirein r/dotnet • Mentions

On “Why does everything have to use interface?”

Not OP, but I also used to think unit tests should test every single class independently. Especially after watching The Magic Tricks of Testing by Sandi Metz, I thought I knew how to test properly. The video is still fantastic and teaches you the right concepts, don’t get me wrong. But defining units at such a low level makes testing take a significant amount more time. In my experience that’s not proportional to the value. Just like OP (if I understand him correctly), I now consider units to be modules inside a system. Then when you refactor, you don’t have to a) throw away a bunch of tests and b) write a bunch of new tests. This way you can also focus on just mocking the external depe…

u/vocumsineratioin r/dotnet • Mentions

On “Am I thinking of TDD correctly for my project?”

>I'm starting to doubt if I should continue reading this book and am not sure if it is teaching good practices. For those that have read this book, do you have any thoughts to share? Growing Object Oriented Software, Guided by Tests is a *fantastic* book on TDD. But studying it is somewhat complicated by the fact that the tests are designed to "drive" the kinds of designs that the authors preferred, which aren't necessarily closely aligned with the style used by Beck in his examples. (If that's of interest, I've outlined some of the history.) That said, the end-to-end test, and especially end-to-end-test *first,* probably should be understood as a separate idea from "test driven developm…

u/azangruin r/typescript • Mentions

On “Building a game with TypeScript. Drawing Grid 4/5”

>That is why we mock and stub: to minimize outside influence. We mock and stub to isolate the influence of the outside world, yes; but also to check how the unit will interact with the outside world. If you have a Canvas class that, say, needs data from the User class, it's totally fine to mock the User class and to verify that the Canvas class calls expected methods on the User class and passes expected arguments to them. But in your example the Canvas calls its own methods; and it is the testing of these internal calls that bugs me. There's a talk by Sandi Metz regarding unit testing, in the context of query/command separation, in which she draws the following chart: https://miro.medi…