http://devchat.tv/ruby-rogues/185-rr-rails-4-test-prescriptions-with-noel-rappin
podcast-rr-185-rails-4-test-prescriptions-with-noel-rappin#universal-clients1 "One of the advantages of tests is that they're this universal client to your code that gets into all the seams in the code" - Noel podcast-rr-185-rails-4-test-prescriptions-with-noel-rappin#universal-clients1
podcast-rr-185-rails-4-test-prescriptions-with-noel-rappin#deleting-tests1 At 39 minutes he talks about deleting tests (but does not use Kent Beck's scaffolding name)
JESSICA: Exactly. Do you ever go back and delete the ones that were really only useful to drive the design?
NOEL: Sometimes. Again, people get nervous when you start deleting tests. Another thing that's valuable is to just look at, RSpec has a profiler that will just tell you where the slow test, what the slowest tests are. And sometimes it's just valuable to look at the slowest, the very slowest tests and try and figure out what's going on and whether the test is still valuable, why it's slow, and whether it needs to be… invariably, or almost certainly in a Rails application it's going to be slow because it's creating a lot of data. And then the question is just like, is there a better way to do this? So, that can be a valuable thing to do sometimes. podcast-rr-185-rails-4-test-prescriptions-with-noel-rappin#deleting-tests1
The speed of a test is much more important in testing-concept-long-lasting-regression-tests than it is in focused TDD tests used to drive design
he calls them testing-concept-focused-tests
testing-concept-one-assertion-per-test in development but maybe not in testing-concept-long-lasting-regression-tests, which might make more sense as testing-concept-multiple-assertions-per-test
testing-concept-multiple-assertions-per-test can tell a story
complex data structure in rspec is an interesting middle ground
valuable things for testing-concept-long-lasting-regression-tests are speed and naming and helping you pick up context when you don't have context
at 46:
podcast-rr-185-rails-4-test-prescriptions-with-noel-rappin#local-testing-vs-ci1 CORALINE: Noel, we've talked a lot about legacy code and we started touching on test times. And I just have to bring up the fact that when you end up with a long in the tooth Rails application it's not unusual in my experience for local testing not to happen at all and throwing everything over the wall to CI.
NOEL: Yeah.
CORALINE: And that of course ruins the whole point of testing as a feedback loop as part of your design and development. So, what are some strategies [inaudible] that?
NOEL: The best strategy for dealing with that is not to get in that situation in the first place. But of course, once you're in that situation that's horrible advice.
CORALINE: Barring time travel, yes.
NOEL: Yeah, barring time travel. Yeah, I worked at a place and I wasn't a direct developer on that at this place that I'm talking about. But I certainly worked at a place that had all of their testing happen on a very, very powerful CI server farm and it took 30, 40 minutes on the server farm. Nobody had any idea how long it took on a local laptop because nobody in their right mind would ever try to run the test suite on their local machine. podcast-rr-185-rails-4-test-prescriptions-with-noel-rappin#local-testing-vs-ci1
at 48:45 breaking out means not having to run the whole test suite for every change
podcast-rr-185-rails-4-test-prescriptions-with-noel-rappin#pull-out-modules-or-services1 Noel: "Do we need to start pulling functionality out of this app and rewriting this piece by piece in services? Which is effectively what that place wound up doing. They wound up slowly killing off their monolithic Rails application by putting pieces of it into smaller services that interacted. And writing those services hopefully, although I don't know for sure, hopefully those services will be written with faster test suites of their own and then also solve the problem of having to run the whole test suite for every change. But that is a long process that has a long-term benefit and not a short-term benefit. And I think different environments are going to be differently receptive to that." podcast-rr-185-rails-4-test-prescriptions-with-noel-rappin#pull-out-modules-or-services1
podcast-rr-185-rails-4-test-prescriptions-with-noel-rappin#too-complicated1 Noel Rappin said: "I think that tests are a really important guide to knowing if your code is getting too complicated. If it becomes hard to write tests, a lot of people have the situation where they start using testing and maybe they don't refactor or they don't know what to refactor. They know that they should use RSpec but they don't have the experience or a helpful person nearby to guide them through the process. And they get to the point where the code gets a little bit convoluted. And the tests get harder to write, because they need more setup. There are more objects. The objects relate in complicated ways. You need a lot of different objects set up. And then they go, "Oh, these tests are really hard to write. I give up."
And I think the thing is that when the tests get hard to write in a TDD process, you think of that as evidence that the code is too complicated. So, that's a strong guide. If you need to create a lot of different objects in order to run a unit test that tests a single method, that's often a sign that your code is too complicated. Now, what you can do about that is an open question. And it depends on what your setup is. I do not advocate…" podcast-rr-185-rails-4-test-prescriptions-with-noel-rappin#too-complicated1