I believe it is a tradeoff. If you run unit tests that only tests small functions, when it fails debugging is pretty much trivial. With a quick glance you realize: "Oh, silly me! I typed that wrong!". Perhaps so trivial that you spend more time writing the test, than writing the actual code.
If you skip directly to intergration tests for a function that calls various underlying classes/modules you save a lot more time writing tests and quickly get nice coverage, but when it fails you are going to spend more time debugging. You have to pinpoint where exactly is the mistake among a bunch of files.
I think one should be judicious about which test to write in a given situation. You can't generalize and say that one a approach will always be more worthwhile than the other.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I believe it is a tradeoff. If you run unit tests that only tests small functions, when it fails debugging is pretty much trivial. With a quick glance you realize: "Oh, silly me! I typed that wrong!". Perhaps so trivial that you spend more time writing the test, than writing the actual code.
If you skip directly to intergration tests for a function that calls various underlying classes/modules you save a lot more time writing tests and quickly get nice coverage, but when it fails you are going to spend more time debugging. You have to pinpoint where exactly is the mistake among a bunch of files.
I think one should be judicious about which test to write in a given situation. You can't generalize and say that one a approach will always be more worthwhile than the other.