There’s a lot of posts out there where people will tell you how to do something. How you must do something in a certain way. How you’re not a real developer unless you do things in this particular way. I hate that sort of post.
I strongly believe that there isn’t such a thing as a best practice. There are effective practices that work well in certain contexts, but might be less effective in other contexts - although I’m pretty confident that some practices aren’t effective in any context. I do, however, think there’s a lot of value to be found in taking a practice that’s successful in one context, and finding ways to adapt or generalise it into more contexts.
So with those caveats out of the way, here’s a post that tries to explain and justify how I personally write my automated tests. These approaches have been shaped over the years by my own experiences but also by the opinions of my colleagues and how well (or not) we’ve seen them work.
The techniques I’m writing about here are the ones I’ve found to be successful when building products that run as cloud-native software that is continuously or frequently deployed to a server environment and consumed by users over the Internet.
I’ve made an attempt to separate these ideas into distinct headings, but in practice they are very interrelated in my mind.