This week we talk about testing state coverage, not code coverage, finding bugs once, building documentation in, and signing your work.
John: Welcome to Iteration: A weekly podcast about programming, development, and
design through the lens of amazing books, chapter-by-chapter.
JP: This is part 2 of Chapter 8 - THE FINAL CHAPTER!
Identify and test significant program states. Just testing lines of code isn't enough
JP: Even if you test every single line of code - that's not what matters. What matters is how many different permutations of your app's state you have covered. drops mic
John: Coverage tools are nice - but they only give you a window into the state passed into it. If you can extract state out into separate objects or methods to be able to test them decoupled from time.
Once a human tester finds a bug, it should be the last time a human tester finds that bug. Automatic tests should check for it from then on.
JP: We don't have time to find a bug more than once... "We have to spend our time writing new code - and new bugs"
John: Step one of debugging - write a test that's failing. I broke this pattern this weekend. :(
Write docs as you would write code: honor the DRY principle, use metadata, MVC, auto-generation and so on
JP: don't dread writing docs. it's part of your application. I think this tip is phrased in such a way to appeal to engineers. think of documentation writing as writing code, not writing literature
John: I like this in theory - I'm having trouble getting tooling in place for this that makes sense. I really want to dynamically generate, external API docs, internal docs and user guides totally automatically. Super struggling to get anything moving in rails.
Documentation created separately from code is less likely to be correct and up to date
JP: sometimes you need documentation. obviously, name your variables well, but sometimes explain what a function does or why it does it. at OL we'll sometimes write include the GitHub issue number for a weird quirk or to explain why a test is testing for certain functionality. treat docs like code. part of the code, not separate from it
John: I feel like this is a bit outdated. If written well modern languages really can be self-documenting. Basecamp really doesn't "do" code comments or internal docs - Per DHH - If there is a comment explaining a method or model I break it up further until it doesn't need explaining. I worship in the church of Henninger-Hansen.
Come to understand your users' expectations, then deliver just that little bit more.
JP: "Never lose sight of the business problems your application is intended to solve".
John: One of my favorite parts of the job is delivering features users get super jazzed about.
Craftspeople of an earlier age were proud to sign their work. You should be, too
"Anonymity, especially on large projects, can provide a breeding ground for sloppiness, mistakes, sloth, and bad code. [...] We want to see a pride of ownership. Your signature should come to be recognized as an indicator of quality. A really professional job. Written by a real programmer. A Pragmatic Programmer"
JP: lol, git blame
John: Take pride in what you do.
Picks
JP: https://github.com/sindresorhus/refined-github
John: LG 22MD4KA-B UltraFine 4K Display 21.5" UHD 4096x2304 4xUSB-C
Next week: Pragmatic Programmer in Practice - Book recap in the context of our real-life development work.