Try to only write tests for public/exported methods. Don't test internal functions (there will be exceptions as with anything but this should be a general rule)

Try to only write tests for public/exported methods. Don't test internal functions (there will be exceptions as with anything but this should be a general rule). Design your interfaces and method signatures in a way which would minimize future need for changes. For example, do not pass configuration options to your module as option1 and option2, instead wrap them in options/config object and pass that to your module. This allows you to add more configuration options in the future without having to break any existing interface. Finally, when it comes to brittle unit tests, an extra layer of functional / integration tests is what you should have. These tests will be less brittle as they will break in more cases (i.e. if there is an issue on the edges of "units" of your codebase). The tradeoff will be that functional/integration tests will be slower and more difficult to execute (I suggest using docker-compose to run integration tests in a platform agnostic way).