Clojurians Log v2

Here is a cool overlap: Brian Marick who wrote this tutorial on Clojure zippers: http://www.exampler.com/blog/2010/09/01/editing-trees-in-clojure-with-clojurezip ... is an original signer of the https://agilemanifesto.org with a specific interest in software testing. http://exampler.com/testing-com/writings/classic/mistakes.pdf by him is a classic article. About the mindset of testing itself: https://context-driven-testing.com has some principles None of this is about automated testing though. https://martinfowler.com/bliki/TestPyramid.html and https://www.thoughtworks.com/insights/blog/introducing-software-testing-cupcake-anti-pattern is also in the conversation.

I don't have a book recommendation about automated testing specifically. Actually I would be interested in recommendations as well. I think a typical approach would be to look for books about TDD but then pick and choose aspects and techniques from it that you find valuable. TDD is a methodology that you don't need to fully subscribe to to get value from. However, I think you can look at testing from different angles as well: A book I have read quite a few years ago but still cherish is "Debugging: The 9 Indispensable Rules for Finding Even the Most Elusive Software and Hardware Problems" It presents a set of heuristics that you can apply to finding problems. Debugging and testing are in many ways closely related in terms of what mindset you need to emerge yourself in. Another relationship is error handling and fault tolerance. I still have some papers on my todo list regarding this. Again, a similar mindset applies. What I would also recommend is going through Tiger Style by Tigerbeetle. They are doing very advanced automated testing, which includes simulations, integration tests, very regular benmarking and so on. Their code is open source (Zig), and is very readable even if you're not familiar with the language or what they do, because they take great care of the code, comments and so on. They also have some excellent talks about it.

oh I almost forgot: Here is of course an excellent verification and testing framework written in Clojure. This goes of course way beyond regular automated testing, but I think it would be worth studying or trying out: https://github.com/jepsen-io/jepsen

Not a book, but just one thing that helps I believe is to understand there are two distinct uses of tests: 1. To catch bugs in your code and fix them in order to be sure the code works. This can be as simple as manually testing the program and seeing if there is anything that doesn't work or errors. 2. Once you have something working as expected in the program, you want to make sure that in the future it continues to work even as you modify the program or infra further. These are called "regression tests". You want to have an automated way to re-run tests for things that work as expected so that if they break in the future you can catch the regression. And you want to run those tests each time you change something about the program. Those are the tests that you commit alongside your code.

@didibus that is the broadest definition of regression test. The term is often used more narrowly: write a test that reproduces a specific bug, then keep it around to ensure that future changes to let the same bug emerge. I found that these specific regression tests are very valuable. Because you already have real life proof that the issue exists and writing the test can be part of the debugging process as well and documents its reproduction.

I've been thinking about this recently and have found some books somewhat lacking in this regard as well. David Farley's Modern Software Engineering is ok, but like a lot of programming books the examples it gives are too simple and abstract to give an idea of how to apply them. It spends a lot of time with toy Java examples showing "modularity" that is basically achieved "for free" in Clojure by using pure functions. Still might be worth a look. As far as mindset goes, I think this meme sums it up. If your tests don't exercise a property worth asserting in production, and aren't written to run against production data in some capacity, they're more for your benefit than the system's.

Maybe, The Pragmatic Programmer?