Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
-
@Lensflare coverage % in JavaScript is based on lines that code visited. so if the test is empty it wouldn't have visited the lines
asserts are another matter tho
coverage I would assume everywhere would be based on the lines the code visited so other than asserts should work -
That is unfortunate but bit something you can't overcome. If you know the behaviour of the app/service/script you can fairly quickly reimplement the tests correctly.
Start with end to end tests. You should be able to test the thing mostly without exploding the number of test cases.
Only with certain high in logic pieces unit tests pay off. (That is not 100% true but close enough). This will drastically lower the amount of tests while still having high coverage. Unfortunately sometimes e2e tests can be dog shit slow on some platforms. More of an integration test style can help than (while basically trying to test the outside behaviour).
I'm rewriting this horrendous piece of software that's like, real ugly, I mean, seriously ugly. A non stop mess of global variables and aliases and logical tantrums and fuck I know what else...
That's until today.
Today, after a ton of time spent clenching 2k LOC of ASS into readable 1.2k LOC, all tests passing, and passing faster if I may...
Then came a horrifying realization...
It downed on me, harder than a naked superman for a young Louis Lane
Tha maybe, just maybe, if them codes 's só shitty then probably so is them tests
So I tried deleting a obviously important conditional and to my dismay... oh boy, tests kept passing
...
rant