When Should I Use Unit Tests and How to Approach Them?

You’re spot on about unit tests being a safety net. They help answer the question, 'What could break if changes are made?' Testing doesn't just apply to complex functions but is wise for all code, including the simple ones. You have no idea who might tweak a function down the line.

As for quantity, aiming for at least one test per function is a solid minimum, but include a mix of both edge and common cases, especially if the failure could lead to significant issues. Remember that tests can only be as good as what you write, so think through potential risks.

On the topic of scale, it's absolutely viable to write tests for every function if your code is deterministic and returns consistent results. Start with unit tests for individual functions and expand from there. You can also implement tests for groups of functions or entire classes as you go. Ultimately, the scope depends on your project's requirements and the potential impact of failures.

Don’t strive for 100% coverage if it’s unnecessary—focus on the critical paths to keep your testing efforts effective without overwhelming yourself.

I think you've touched on a crucial point. Simple functions can have unexpected side effects, like logging errors or handling edge cases. For example, what happens if someone passes in a string instead of a number? Does your function exit gracefully or throw an error? You need tests to ensure those paths are handled correctly.

Testing isn't just about catching bugs. It’s also about ensuring your code continues to function after modifications. If a future developer changes your function, tests ensure they don’t inadvertently introduce bugs, preserving functionality while allowing for improvements.

Great question! Taking your square root function as an example, if it simply calls an existing library function, then testing it might seem redundant. However, if you've coded your own version using something like Newton's Method, you'd definitely want tests to ensure it functions under various conditions. Bugs can sneak in, especially with edge cases like negative inputs or very small numbers.

As for where to put your tests, it’s best to keep them in the same code repository and ensure they’re easy to run whenever you update your code. This way, you can catch problems before they reach production.

In terms of how many tests to write, a common goal is to cover every line of your code with at least one test. If the logic branches (like "if" statements) are present, you’ll want tests for both outcomes. And remember, focus on the public methods if you're testing a class—you don't need to test private helpers if they're not exposed anywhere else.

In terms of what to test, you should look to include both the happy paths (valid inputs) and the unhappy paths (invalid inputs). Essentially, your unit tests should cover a variety of use cases.

Think of it this way: testing is your best friend in development. It’s about finding mistakes before they reach users, ensuring that changes made don't break existing functionality, and guiding future developers who might not know the nuances of your code. So yeah, while testing can seem daunting, it's well worth the effort!