Some people avoid writing tests. Some drudge through it painfully. There is a better way. In this episode, I’m going to share some advice from Luke Plant on how to “Test Smarter, Not Harder”.
Transcript for episode 131 of the Test & Code Podcast
This transcript starts as an auto generated transcript.
PRs welcome if you want to help fix any errors.
00:00:00 Some people avoid writing tests. Some Drudge through it painfully. There is a Better way. In this episode, I’m going to share some advice from Luke Plant on how to test Smarter, Not Harder. Thank you, Talk Python Training for sponsoring this episode. Do you want to get better at Python On? Now is an excellent time to take an online course. Whether you’re just learning Python or you need to go deep into things like APIs or Nasync, our friends at Talk Python Training have a top notch course for you. Stick around until the end of the show to hear a way you can win a free course. Visit Talk. Python. Fmtest to find your next level that’s talkpython. Fmtest.
00:00:52 Welcome to Test and Code Testsmarter Not Harder is the name of an article by Luke Plant. I ran across it recently and it’s got some really pretty good advice. I’ll link it to it in the show notes, but really, I’m going to read most of it here with Luke’s permission. Well, there’s some rewording and summarizing, but I hope I convey the intent well, so here goes.
00:01:22 Smarter, Not Harder is a saying used in many contexts, but rowing is the context. I think I first heard it in, and I still associate it with rowing many years later. When you look at novice and more experienced rowing crews, it seems particularly appropriate because the primary difference is not the amount of effort that goes in, nor even the strength of the rowers, but technique. Poor rowers still finish a race absolutely exhausted, but they’ve moved at a fraction of the speed of better crews. Sometimes the effort they’ve put in actually slows the boat down.
00:01:57 They tend to make a lot of noise and splash a huge amount of water in every direction. Expert crews, however, do none of these things because those things don’t make you go faster. These rowers do a huge amount of training and exercise massive amounts of concentration to ensure that every bit of the very large effort they put in is actually contributing to speed. The Smarter, not Harder mindset is also essential in writing good automated software tests. It is in this context that devotion to things like TDD can really be unhelpful. Some people don’t enjoy writing tests during TDD, but do it anyway in great volume, partly to atone for not writing tests in their past.
00:02:41 If you take that mindset with you into writing tests, you will do a rather bad job. If writing test is extremely painful, it may be a sign that something is wrong.
00:02:51 Huge and unnecessary quantities of tests are not a good thing. They’re a massive maintenance burden. Many of the things that make tests hard to write are also going to make them hard and therefore expensive to maintain. I’ve seen far too many examples where it looks like people have just sat back and accepted their painful fate. For example, Robert Martin. I refuse to call him my uncle seems to have this attitude. He wrote, you better get used to writing lots and lots of tests, no matter what language you’re using. Don’t listen to Bob. Test Smarter, Not Harder means many things, which we’ll get to right after we thank Datadog for sponsoring.
00:03:34 Thank you, Datadog, for sponsoring this episode. Are you having trouble visualizing bottlenecks and latency in your apps and not sure where the issue is coming from or how to solve it? With Data Dogs end to end monitoring platform, you can use their customizable built in dashboard to collect metrics and visualize a performance in real time. Datadog automatically correlates logs and traces at the level of individual requests, allowing you to quickly troubleshoot your Python applications. Plus, their service map automatically plots the flow of requests across your app architecture so you can understand, dependencies and proactively monitor the performance of your apps. Start tracking the performance of your apps, sign up for free and install the agent, and Datadog will send you a free Tshirt to get started. Visit testandcode.com Datadog Test Smarter, Not Harder means many things. First, only write necessary tests specifically tests whose estimated value is greater than their estimated cost.
00:04:38 This is a hard judgment call, of course, but it does mean that at least some of the time you should be saying it’s not worth it. Second, write your test code with the function method or classes you wish existed, not the ones you’ve been given. You may be able to find an API wrapper that makes your testing job easier. The wrapper library really isn’t important, but the principle is, and if the API you want doesn’t exist yet, you can write it yourself.
00:05:06 Third, don’t write tests for things that can be more effectively tested in other ways and lean on other correctness methodologies as much as possible.
00:05:18 These include code reviews, static type checking, linters like Flake, Eight, Introspection, and selftest systems such as Django’s Checks Framework, or maybe property based testing like Hypothesis.
00:05:32 Fourth, move the burden onto the computer.
00:05:36 Take, for example, a requirement that every entry point in your web app, apart from a few exceptions like Login and password, should require authentication. The test harder approach might be for every entry point, write a test that ensures non authenticated requests returned 403. That’s a lot of tests, and even worse is when you have to remember to write them. The test smarter approach says Write a test that for every entry point, ensures non authenticated requests return four or three. So what’s the difference?
00:06:09 The first one says, for every entry point, write a test. The second one says Write a test that for every entry point that’s one test write a test is executed in developer time. In the first example, the loop for every entry point is also executed in developer time. Push that loop inside of the test and get it executed by the computer instead.
00:06:33 High test parameterization is a great way to push the loop in as is utilizing hypothesis. Lastly, cheat on your homework. It’s smart to get help if you have a good idea but don’t know the techniques or tools you need to implement it or whether it is even possible. There are a lot of smart people on Stack overflow or Twitter or on the Test and code slack channel who will revel in the challenge. An advanced technique is to loudly claim on Twitter that it appears that it is impossible to do X with tool Y and many people will magically appear with solutions. Of course there are still times when hard work is required for writing tests, times when it will be tedious and times when our instincts to skimp are actually misplaced laziness that will cost more in the long run but you should hustle and cheat your way out of unnecessary effort as much as you can. You should feel like AHA I fooled that computer into doing so much work for me not wow my RSI and my sore typing fingers have hopefully appeased the testing gods and atone for my previous omissions.
00:07:43 That’s the end of the article of course I added the test and code slack recommendations as well as the pytest parameterization recommendations. Other changes were made mostly to help with the flow of the spoken versus written form. That’s all. Good advice. Thanks Luke and thanks for letting me share it on this podcast.
00:08:05 Thank you Luke for writing this great article and thank you Datadog for sponsoring check them out at testandcode.com Datadog and thank you to Talk pythonsraining for sponsoring check them out at talkpython. Fmtest. Enter to win a free course by joining the show mailing list at testincode. Comsubscribe and thank you to all the listeners that support the show through Patreon. Join them by going to testandcode.com support all those links as well as links to the articles from the article from Luke are in the show notes at Test And Code.com one, three, one. That’s all for now Luke now go out and test something.