Max Ehrmann reference:

https://en.wikipedia.org/wiki/Desiderata

Used to be you couldn't visit a health-food store without finding that posted somewhere. Then it completely vanished, as if it had never existed, and channelers took over. Even ST-TNG had to get a Ship's Channeler (whom the writers clearly despised). Then channelers evaporated, a fitting end.

Desiderata for Gamers:

https://cantrip.org/gamers-desiderata.html

Upvoted, but noting here to future readers: don’t let above link pass you by without checking it out.

Surprising his tweet blew up, one of the goals of tests (TDD) is to validate your software still works after refactoring. This is a key element of being able to change your code quickly and with confidence. Meaning if you couple your tests to the structure of your code, then it's not going to be quick when you restructure.

I'm the only developer on my team concerned about writing tests. I don't have a lot of experience doing it, and I have no one who can review my tests. Is there anything I can do?

> Is there anything I can do?

Yep.

Start small.

When planning, look for tests that will speed up your work now.

Don't care about overall coverage, only that what you are working on now is reasonably tested.

Always remember: if nobody has told you to test and what test to write then they are just a tool to help you.

Your tests can work as both a

- lab bench, keeping your code in place while you work on it

- fall protection

- a colleague that does pair programming with you, pointing out when you are about to forget something important

If some advice you get doesn't make sense and you can ignore it, do that after trying to understand what it should help for.

Michael Feathers book "Working Effectively with Legacy Code" might come in handy at some point.

Lots of practice, and katas?

Try writing tests to match requirements. Try writing tests, then refactoring to see if it doesn't break the test(still compiles)

I have been a big advocate for testing only the public interface of your code, but sometimes you can't just avoid it, when you have a really complex piece of function, you got to test it to gain confidence. Other than that, I hope these are not a surprise for anybody who is writing tests on a daily basis.

Kent Beck said on a podcast (discussing TDD with David Heinemeier Hansson) that he sometimes writes tests coupled to the implementation details as he's developing, but later (if it seems like a maintenance burden) he will delete those tests.

There's no shame in making public interfaces just for test access. You can change them freely, along with the tests, if needed, if you have given them scary names; or even delete them and the tests that use them, if warranted.

In the hardware world they call this "design for test" and reserve pins or connectors just to attach test jigs to.

I have encountered reviewers who were horrified at the idea, but I just laughed.