4 Comments

If a code base is just a tangled ball of string, where every change is dangerous, my favorite testing strategy is to pick out 1 to 3 essential workflows, and write a very high level UI test for each. This may be hard to set up, but done right, it gives you confidence that the core use case(s) works. For a web app, this might be "create an account, go to the starter page, add a new ______, veiw the _____, do something else to the _____, and make sure we see what the user expects."

These kinds of tests treat the system as a black box, and only rely on things users see. So they tend to be at least somewhat stable.

From there, it's possible to start disentangling one module at a time, as needed to add features. And that module can get some unit tests.

Expand full comment

One can argue that writing good tests will make the production code more structured and with better architecture design - the egg and the chicken problem...

Expand full comment

> Am I comfortable with this change first being executed outside of my direct control when it’s in production?

Someone at Crowdstrike answered "yes" to this question about a month ago, and took down 8 million computers.

I agree with "maybe yes, maybe no" but as an industry we need a lot less "yes" overall.

Expand full comment

I disagree. We should earn a lot more right to confidence, much as aviation has. Okay, not the perfect way example. .

Expand full comment