Do all the things like ++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatarSign Up
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple APILearn More
atheist6756140dIf you have to update your tests when you add a feature, you're probably writing integration/regression tests rather than unit tests. Personally I think they're a waste of time. Unit tests are interesting/useful.
More discussion (op is a bit blunt/controversial, see my later comments): https://devrant.com/rants/4751612/...
Hazarth5551140dWhat @atheist said.
A good unit test should test a *unit* of work, it shouldn't reimplement the whole function a second time to make sure it does what it does.
Really a unit rest should be written for the smallest possible Units of your code and test only for desired behavior at the end if it.
Unit tests are super useful for everyone that wants to change the code later because they can do the Debugging for you specifically. That's actually a decent way to think about them. Whatever you'd write in your console.log()s and Console.WriteLines() when testing in Debug, that's probably what you want written in the unit test, just in a more eloquent way so others know what you're testing
So when you say "good debug tool" that's the shit you want to automate with Units. So you don't have to be the human analyzing what the debug is showing you
nibor5128140dWhen the developers try to maintain the OP's code in the future
atheist6756140d@sariel thing is, that tells you if something has changed. OK, if your service crashes, that's a "big thing that shouldn't happen", but if you fixed a bug, good regression tests *should* fail. For a lot of stuff I've done, "the output is different" is meaningless. I've done computer vision stuff where performance improvements result in tiny numerical differences in the output, they're expected, so it's not a useful validation. Repeatability is also a useful type of test (may be indicative of a threading problem), but even that can be finicky, eg numpy dot product is not repeatable across machines, may depend on cpu intrinsics. See below issue.
arekxv1040137dCode tests are an investment. When project is mostly or fully covered developers get velocity. Need to add a feature? Just go for it and add it, tests got your back so that everything still works. Without tests, how scared are you to add changes to a large codebase? Very scared.
There is also a second use for unit tests. Documentation. API docs are not good enough? Look at the unit tests, they will show you how the specific thing you need is actually used.
So are tests useless? Nope.
hjk1014257137dYou are being adverse to automating something highly repeatable, labor intensive and susceptible to mistakes. Are you an automation professional or a highly paid data entry specialist?
Also the tests are exactly what I run when I use the debugger. Awesome repeatable cases. Make change, abort debug, rerun.
@atheist On API I also like integration/regression tests whatever you want to call them. We have about 70% test coverage (including the 100% API coverage); the API tests prevents any accidents being deployed.
TrevorTheRat1080112dSounds like you aren’t quite writing unit tests correctly.
Test outcomes of your business logic layers now how it happened. Shouldn’t need mocks for that.
Maybe test the how when dealing with testing orchestration layers, you probs need mocks for this. But there is likely to be a lot less of these tests too.
If your unit tests are hard it can be a good indicator that your code could be improved.
Don’t just press forward with them, think about what the feedback loop is telling you.
Seen devs spend ages writing a unit tests for greenfield code. Tests that were crazy hard and when you look at the code it was testing that was the real issue.
ars11715106dI fucking love unit tests