Koodihommia

I write a lot of stupid and useless unit tests. I confess that I'm aiming towards the elusive 100% test coverage. Sure, I'll never get there, and I realize it is not even a desirable goal. After an assessed threshold, we start to get diminishing returns. Why do I keep writing wrong tests then? Which unit tests should I leave out? My case is that it is tricky to write a large codebase with only valuable tests. I dare say that some (minority) of the essential tests might have outright bad practices where they end up testing how well I can mock stuff. The value of the test is not predetermined; hence I keep writing a lot of seemingly poor ones. There is an argument that high test coverage does not strongly reduce bugs and increase maintainability. That is likely true. Nonetheless, it is not so apparent which tests will avoid the most bugs or are the most useful in refactoring in the long term. The cliché is that requirements change, sometimes towards unknown directions.  It is mor