Mike Schutte is a fronted developer at TED conferences and was trained in code school at Turing in Colorado. He likes the idea of code as a communication tool, and in 2018 he gave a talk at RailsConf called Stop Testing. Start Storytelling.
Today the panel is discussing what Mike means by storytelling in testing. In order to combat the hesitancy to start testing, Mike believes that changing your mindset to think away from the implementation details while deploying these tests can help them be more efficient. In short, if the test isn’t readable by a non-developer, then it’s not telling a story, it’s just writing code. The test is almost the first point of contact away from the source code, so if that’s unwieldy in a test it will be hard to use elsewhere in the application. We have an intuition for stories, so use tests in order to communicate the intent of what the application should do under certain conditions. If it’s hard to set that up in a succinct way then maybe it should be written differently.
This view is backed up by other experts as well. Sandi Metz and Noel Rappin talk about it in Tech Done Right episode 69. They say if your test isn’t easy to write and you’re having to create tons and tons of objects, then the system or the class your trying to test is too interconnected, so you might want to break that up into more separated concerns so each of your tests can be focused on what you’re actually trying to test. If you follow these principles, your testing will be a lot easier even if there are more classes and modules to test. David applies this approach to an online shopping cart and how to break it up. The idea is to abstract it away from the big picture, in this case the grand total, and breaking it down into smaller stories or things.
Mike shares methods to put this approach into practice and how to test. He finds that reading the code as if you were reading a section in a novel rather than code helps him sketch out what he needs to test. The panelists discuss different methods for testing, emphasizing keeping the models or classes you write very simple, minimizing the amount of full on feature specs. If you take time to think about the mindset and the process you use to write a test, the tools you use becomes interchangeable in a lot of ways.
Andrew brings up a trend that he’s noticed of tools coming out that are taking mini tests or rspec and trying to morph it to the programmer’s preferences. Tools like this end up with a lot of weird syntax that is hard to maintain. The panelists acknowledge the challenges that stem from using a custom VIM, and believe that having an agnostic approach makes it easier to jump into different systems. Your focus shouldn’t be your developer preferences or what you’re used to, rather it should be your happiness when you have to update. They agree that because it’s easy to understand, it’s telling a story the reader can understand, which makes it easier to maintain in the long run.
With special guest: Mike Schutte
Sentry use the code “devchat” for 2 months free on Sentry’s small plan
Cloud 66 - Pain Free Rails Deployments Try Cloud 66 Rails for FREE & get $66 free credits with promo code RubyRogues