The Bike Shed

438: Writing abstractions in tests

The Bike Shed

Writing abstractions in tests can be surprisingly similar to storytelling. The most masterful stories are those where the author has stripped away all of the extra information, and given you just enough knowledge to be immersed and aware of what is going on. But striking that balance can be tricky, both in storytelling and abstractions in tests. Too much information and you risk overwhelming the reader. Too little and they won’t understand why things are operating the way they are. Today, Stephanie and Joël get into some of the more controversial practices around testing, why people use them, and how to strike the right balance with your information. They discuss the most common motivations for introducing abstractions, from improved readability to simplifying the test’s purpose and the types of tests where they are most likely to introduce abstractions. Our hosts also reflect on how they feel about different abstractions in tests – like custom matchers and shared examples – outlining when they reach for them, and the tradeoffs and benefits that come with each. To learn more about how to find the perfect level of abstraction, be sure to tune in! Key Points From This Episode: What’s new in Joël’s world; mocking out screens for processes or a new bit of UI. The new tool Stephanie’s using for reading on the web: Reader by Readwise. Today’s topic: controversial practices around testing. How Stephanie and Joël feel about looping through arrays and having IT blocks for each. The most common motivations for introducing abstractions or helper methods into your tests. Pros and cons of factories as abstractions in testing. Types of tests where Joël and Stephanie are more likely to introduce abstractions. Using page objects in system tests to improve user experience. Finding the balance between too little and too much information with abstraction in testing. Why Stephanie has been enjoying fancier matchers like RSpecs. Top uses of custom matchers, especially for specialized error messaging. Why Stephanie prefers custom matchers over shared examples. Using helper methods as a lighter version of abstraction. Differences and similarities between abstractions in tests versus application code. A reminder to keep your goals in mind when using abstraction. Links Mentioned in Today’s Episode: Reader by Readwise (https://readwise.io/read) Why factories (https://thoughtbot.com/blog/why-factories) Why not factories (https://thoughtbot.com/blog/speed-up-tests-by-selectively-avoiding-factory-bot) Capybara at a single level of abstraction (https://thoughtbot.com/blog/acceptance-tests-at-a-single-level-of-abstraction) Writing custom RSpec matchers (https://thoughtbot.com/blog/acceptance-tests-at-a-single-level-of-abstraction) Value objects shared examples (https://thoughtbot.com/blog/value-object-semantics-in-ruby) 'DRY is about knowledge' (https://verraes.net/2014/08/dry-is-about-knowledge/) Joël Quenneville on LinkedIn (https://www.linkedin.com/in/joel-quenneville-96b18b58/)

Next Episodes



The Bike Shed

435: Cohesive Code with Jared Norman @ The Bike Shed

📆 2024-07-30 21:00 / 00:28:45


The Bike Shed

434: Git and GitHub Workflows @ The Bike Shed

📆 2024-07-23 21:00 / 00:47:42


The Bike Shed

433: Riffing with Kasper Timm Hansen @ The Bike Shed

📆 2024-07-16 09:00 / 00:37:20