使用Player FM应用程序离线!
The Steering Premise | #98
Manage episode 279839989 series 2644918
Microtest TDD's Steering Premise is quite simple, which may be why it sometimes meets furious opposition. It says "Tests and testability are first-class citizens in design." Let's talk that over a little. There are, for any software problem, an infinite number of functionally correct designs. If implemented, they will work. But we don't *implement* an infinite number of designs. Why not? Because though they may be functionally correct, they still don't fit our context. We reject designs -- more often we reject individual choices in designs -- for a variety of reasons: reliability, cost of hardware, poor fit to our toolset, and so on. Those reasons are the "citizens" of the design process. And the steering premise says that one of the citizens -- not a secondary or minor or ex post facto consideration -- is whether that design can be tested. To probe at it: If you brought us a functionally correct design that required our app to run on a million AWS instances, we'd casually say "no, that's not valid." So obvious is this conclusion, that no one ever does it. Designs don't even get that far with such an issue.
---
You can read the full transcription of this podcast over on GeePawHill.org. Any feedback, you can always tweet @GeePawHill on Twitter, or drop a voice message via the voice messages link here on Anchor. If you are interested in becoming more involved in the Change-Harvesting community, click here to learn how to join GeePaw's Camerata.
--- Send in a voice message: https://podcasters.spotify.com/pod/show/geepawhill/message147集单集
Manage episode 279839989 series 2644918
Microtest TDD's Steering Premise is quite simple, which may be why it sometimes meets furious opposition. It says "Tests and testability are first-class citizens in design." Let's talk that over a little. There are, for any software problem, an infinite number of functionally correct designs. If implemented, they will work. But we don't *implement* an infinite number of designs. Why not? Because though they may be functionally correct, they still don't fit our context. We reject designs -- more often we reject individual choices in designs -- for a variety of reasons: reliability, cost of hardware, poor fit to our toolset, and so on. Those reasons are the "citizens" of the design process. And the steering premise says that one of the citizens -- not a secondary or minor or ex post facto consideration -- is whether that design can be tested. To probe at it: If you brought us a functionally correct design that required our app to run on a million AWS instances, we'd casually say "no, that's not valid." So obvious is this conclusion, that no one ever does it. Designs don't even get that far with such an issue.
---
You can read the full transcription of this podcast over on GeePawHill.org. Any feedback, you can always tweet @GeePawHill on Twitter, or drop a voice message via the voice messages link here on Anchor. If you are interested in becoming more involved in the Change-Harvesting community, click here to learn how to join GeePaw's Camerata.
--- Send in a voice message: https://podcasters.spotify.com/pod/show/geepawhill/message147集单集
Alle episoder
×欢迎使用Player FM
Player FM正在网上搜索高质量的播客,以便您现在享受。它是最好的播客应用程序,适用于安卓、iPhone和网络。注册以跨设备同步订阅。