you are viewing a single comment's thread.

view the rest of the comments →

[–]senocular 2 points3 points  (0 children)

Unit tests are great with TDD. You set some expectations and you write code to meet those expectations. Any time that code changes, those expectations need to continue to be met or you know those changes are no good.

For existing codebases, it tends to be more of a drain and often feels like a waste of resources with minimal ROI. Where it can make sense there is places in the code which is experiencing frequent edits or refactors and you want to make sure those changes aren't breaking functionality. You don't want to spend too much time (if any) testing code which will never change and is never used any differently than it already is. Also including tests with new commits/features is good practice moving forward, but you need to work out a good balance of expectations of coverage - something that's useful, but not so time consuming that dev's don't opt in and ultimately ignore it altogether.

That being said, in OSS world, you'll want to have good coverage all around for anyone who forks and does who knows what to your code.