# Design for Testability

DevFeed: [Design for Testability](<https://devfeed.tech/articles/design-for-testability-21938.md>)

Original publisher: [Read original article](<https://blog.nelhage.com/2016/03/design-for-testability/>)

Author: Nelson Elhage

Published: 2016-03-06T10:00:00Z

Content type: opinion

Language: en

Sources: [Nelson Elhage](<https://devfeed.tech/sources/nelson-elhage.md>)

Topics: [Code](<https://devfeed.tech/topics/code.md>), [test](<https://devfeed.tech/topics/test.md>), [Development](<https://devfeed.tech/topics/development.md>), [Software](<https://devfeed.tech/topics/software.md>)

Tags: [automated](<https://devfeed.tech/tags/automated.md>), [code](<https://devfeed.tech/tags/code.md>), [test](<https://devfeed.tech/tags/test.md>), [tests](<https://devfeed.tech/tags/tests.md>), [unit-tests](<https://devfeed.tech/tags/unit-tests.md>)

## AI overview

The article argues that software should be designed for testability. It recommends evaluating abstractions and interfaces by asking how they can be tested with automated tests and minimal irrelevant dependencies, emphasizing fast unit tests alongside integration tests.

## Source excerpt

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?