This article isn't about when you should test. A person might not need to test a webpage, ui, or game logic. If the code is part of an API or library you'd likely want to test it.

Don't Test Private Functions

Should you test doExtraWork in this example?

class MyClass {
	int specialCase = 0; //never changed
	void doExtraWork(int value) { /* complex code */}
	public void doWork(int value) {
		//code
		if (specialCase) {
			doExtraWork(value);
		}
		//code
	}
};

No, never. Doing so will make it less obvious when the code is dead. You may keep around variables/code/conditions that you don't need, or spend time refactoring code never executed. I like and write a lot of tests, I like to start with black-box testing

Black-Box Testing

In short, you don't look at the implementation of what you're testing and you see if it works as expected. I start with common cases, less common but not rare, error cases then cases with min/max values if it's important enough to handle early. One advantage of starting with black box testing is you're not locking down your implementation early in the process. You can change any behavior easily when there are only a handful of tests.

Test Coverage

Once my code is almost production ready, I start writing tests for code coverage. Code coverage tells you which lines were executed and how much of the file is covered. If an if-statement is never entered it could mean that code is dead but more likely you missed a case in your test. A major problem with coverage is that you can run lines without checking the result. If you have a struct with 5 values and an if-statement changes one of them, you can easily run it and forget to check the value making it look like you tested it without actually testing it. All you may know is that it didn't throw an exception.

You should keep the percentage to yourself. Depending on the project I aim for 90% on most code, 80% for code that's taking a few days but not finished, and nearly 100% for code heavily relied on, especially if it won't be obvious when incorrect. Code that manipulates data structures I almost always try to have 100%.

Test Goals

1. Confirm output is correct (may only be correct on the target platform)
2. Inform you when your changes break something (important while refactoring)
3. Have a place to introduce/run new code incrementally.
4. Have a suite that'll tell you what's not working as you port code to another platform.
5. Bonus: You may have fuzz tests where your goal is to never have an exception or to never take longer than a few milliseconds

All of these goals are fine goals. None involve a specific implementation. If a test accesses a private variable or calls a private function something has gone wrong. It's very likely those tests will become a hindrance. If your code is wrong going through public functions, you may lose all confidence in your code and your tests. Don't ever test private functions.