I'm transitioning from personal projects to team-oriented work and I find myself needing a more structured approach to testing. However, I'm wary of spending too much time—like 80% of my efforts—just writing tests.
I have several considerations:
- What aspects of the code are really worth testing?
- How in-depth should my tests be?
- Is aiming for 100% coverage beneficial, or does it eventually become excessive?
- What tools should I be using for testing?
Here are my specific questions:
- Should I test everything or prioritize the critical paths in my code?
- What's a reasonable ratio of tests to code?
- When do you think it's best to write tests—before or after coding (test-driven development)?
- How should I handle external dependencies like APIs and databases in my tests?
- Do most people prefer unittest, pytest, or other tools?
- As my project grows, how should I organize my tests?
I'm aiming for a sustainable testing approach that allows me to catch bugs efficiently, refactor with confidence, manage test maintenance, and have a clear strategy for testing.
4 Answers
The 80/20 rule is often effective! I’ve experimented with TDD but sometimes it complicates things unnecessarily. I prefer to get my code working first, and then refactor before implementing tests to keep everything maintainable.
I usually advocate for meaningful tests. Don’t 'chase' coverage percentages. Instead, focus on ensuring every important feature has tests backing it up. This approach will lead to good coverage naturally. Also, remember that you should always write a test that recreates any bug you find; this helps prevent regressions later on! TDD isn't always practical; rather, write your tests as you develop functionalities.
Each team usually has its own rules regarding test coverage, so it's best to follow those when working collaboratively. Personally, I believe in having unit tests for all important functionality, and I often use pytest for that. It really helps ensure that any non-trivial logic has adequate coverage!
When it comes to testing, it's important to focus on unit tests mainly. Target the main paths through your components and make sure to include tests for edge cases and invalid inputs that should raise exceptions. You don’t need to write trivial tests just to increase line coverage—just ensure you're hitting the important aspects. If you find bugs in production, you likely need more tests! As for coverage, aim for around 80%, beyond which the returns can diminish. As for organizing tests, I suggest keeping all test cases in a subdirectory labeled 'tests' and having individual files for components with functions over classes for simplicity. Also, don’t shy away from automating integration tests!
Do you find this holds true even in frontend development?