<?xml version="1.0" ?><entry xml:lang="en-us" xmlns="http://www.w3.org/2005/Atom" xmlns:planet="http://planet.intertwingly.net/"><id>https://blog.nelhage.com/2016/03/design-for-testability/</id><link href="https://blog.nelhage.com/2016/03/design-for-testability/" rel="alternate" type="text/html"/><title>Design for Testability</title><summary>When designing a new software project, one is often faced with a glut of choices about how to structure it. What should the core abstractions be? How should they interact with each other?
In this post, I want to argue for a design heuristic that I’ve found to be a useful guide to answering or influencing many of these questions:
Optimize your code for testability
Specifically, this means that when you write new code, as you design it and design its relationships with the rest of the system, ask yourself this question: “How will I test this code?</summary><updated planet:format="March 06, 2016 10:00 AM">2016-03-06T10:00:00Z</updated><source><id>https://blog.nelhage.com/post/</id><author><name>Nelson Elhage</name></author><link href="https://blog.nelhage.com/post/" rel="alternate" type="text/html"/><link href="https://blog.nelhage.com/post/atom.xml" rel="self" type="application/rss+xml"/><subtitle>Recent content in Posts on Made of Bugs</subtitle><title>Posts on Made of Bugs</title><updated planet:format="September 15, 2026 01:37 PM">2026-09-15T13:37:03Z</updated><planet:format>rss20</planet:format><planet:bozo>false</planet:bozo><planet:items_per_page>60</planet:items_per_page><planet:name>Nelson Elhage</planet:name><planet:css-id>nelson-elhage</planet:css-id><planet:days_per_page>0</planet:days_per_page><planet:http_etag>&quot;5b2ae9eec2e293572f6ae5a000bd0161-ssl-df&quot;</planet:http_etag><planet:http_status>200</planet:http_status><planet:encoding>utf-8</planet:encoding></source></entry>