little rant?
my programming job requires 100% test coverage for the codebase. sounds reasonable, good code practice. however, we also have many files that are mostly or entirely static data (configurations and data driven stuff, I guess). these also need tests for some reason. so the tests usually end up being one of the following:
1. compare parts of the data with a copy of itself to make sure it matches (pointless)
2. assert that each individual field in a dictionary/list exists (just option 1 but overcomplicated)
3. count up fields/items and make sure the total matches (best approach imo but still feels like it's not needed)
like, okay. the point of writing test cases is to make sure that the expected result of a function matches the actual result outputted by the function. if you're instead testing data, the expected result is already right there - it's just the data. you can just look at it to make sure it's what's expected. and I guess test cases are also to make sure random parts of your code don't unexpectedly break when you change other parts. sure. but this is just data - no other part of the code should or would ever be changing it.
anyway, in my eyes, what seems like a good coding practice is extended places that it is not necessary and should not be used. it mainly ends up making PRs more verbose and take a long time.
p.s. I think it's weird that we have a lot of data and configs like this written in python itself. why not json or something? some files will even have a huge chunk of data followed by a little class at the bottom. just seems like a slightly odd way to do it to me.
