Hi all #software folks 👋
When you do #UnitTest, how do you organise them in your code base?
I often find that I lose track of tests, and when I want to know “is this thing tested?”, then I don’t know where to start looking.
Sometimes I set a breakpoint in the thing and run all tests and see what hits the breakpoint, which is not smart.
When reviewing a PR for new stuff, I can look for added tests. But for changes to existing stuff, I don’t know where to find and check existing tests.
=> More informations about this toot | More toots from eldamir@hachyderm.io
@eldamir Some stuff at work is best covered by a sort of integration test (spinning up the web server w/ a test database and running HTTP calls), which sometimes can take effort to find.
I've found that the best thing to do is to run the test suite with coverage analysis on. Takes about half a minute on our codebase.
=> More informations about this toot | More toots from cvennevik@hachyderm.io
@cvennevik for a moderately disorganised test suite, I think the coverage report would be the best way to get any sense of what is going on.
And maybe that data can help inform a cleanup of the tests.
Cleaning up tests would require a design for what the target state is. And that target is a bit blurry for me.
I’ve never worked with teams who had this figured out, so now I’m taking it to the Fediverse for inspiration ❤️
=> More informations about this toot | More toots from eldamir@hachyderm.io This content has been proxied by September (ba2dc).Proxy Information
text/gemini