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 에피소드
모든 에피소드
×플레이어 FM에 오신것을 환영합니다!
플레이어 FM은 웹에서 고품질 팟캐스트를 검색하여 지금 바로 즐길 수 있도록 합니다. 최고의 팟캐스트 앱이며 Android, iPhone 및 웹에서도 작동합니다. 장치 간 구독 동기화를 위해 가입하세요.