It's about time for the Ruby community to adopt a more mature and nuanced approach to testing. Gone are the days when "is it tested?" was a boolean question. It no longer makes sense for a single test suite to accomplish numerous objectives, because the design of our tests are so influenced by the benefit we hope to realize from them. What's less clear to most developers is the best approach to breaking a test suite up. This talk will introduce a testing architecture that's appropriate for the post-monolithic age of Ruby application development. We'll discuss why each test suite can provide at most one type of confidence and one type of feedback. I'll introduce a set of five narrow, focused types of test suites and explore how each of their roles can combine to provide all of the value that test automation can hope to offer. Together, we'll gain the ability to discuss the value of each test with much greater precision and subtlety.