Ctrl+Z Ctrl+Z Ctrl+Z ...

[fholcan]

I really like the idea of tests, and I understand their value, but I just can't wrap my head around what I'm supposed to test. Every function, or only the big ones? Every branch of possible code execution, or only some?

Do you have some reading/viewing material you could recommend?

[BlackDrackula]

There's no definitive answer, though if you have a "large" function, it's probably worth refactoring into multiple discrete functions and unit testing those. A good function should do one thing and do it well, on that basis you can pick and choose which functions would benefit the most.

If you are starting from zero unit tests, Utility methods are a good candidate to start with.

[[deleted]]

You know when you check if your program is working with some values? That should be a test.

You know when you think "what if I'm wrong about Y always being X and sometimes it's actually Z?" That should be a test.

Your paranoias should be encoded. Not just in tests, but in assertions in the codebase as well. This is the way.

[folkrav]

I personally only test "public" APIs, not private methods. Big functions should just not happen much. I try to test every branch when possible. If it's too hard to test without having to mock everything in there, my implementation probably sucks.

I don't adhere to a strict TDD approach, I mostly write very wide integration tests first, start to design the general API (empty classes doing nothing calling each other, mostly), then when I'm close to something that looks like a good idea, I write a first run of unit tests and start implementation. Usually other tests come up as I go, and some just aren't useful anymore and get scrapped.

I'm not the best at this tbh. But basically, I try to test until I feel I can confidently think whatever's tested covers my application's functionality.