The only reason to not spend a lot of time writing tests is that you are an amazing coder, in that case you'll write all the tests much faster. Code without testing is incomplete code. Code without testing is like an UFO sighting swear to me that works, I still need proof. If the test is written after, during or before the code is, in my opinion, debatable and a matter of taste. But if is not properly tested is not finished, is not working code.
Very well said. Tests as evidence the code works is another great way to view them, since it gives an understandable measure of "ready or not ready" for everyone in the company. Leaving it to the engineer's word only risks damaging the relationship between departments when bugs inevitably slip through.
And I also like them to be a sort of documentation, I usually end up commenting more about the intent in the test than in the code; almos like a tour of the code in the tests.
Why just say what something do when you can show it and prove it in the tests; I'm starting with Rust and like Python you can add automagically some comments to the docs. Documenting and testing, two birds.
And you make sure is not stale, because those are tests that have to work.
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.
The only reason to not spend a lot of time writing tests is that you are an amazing coder, in that case you'll write all the tests much faster. Code without testing is incomplete code. Code without testing is like an UFO sighting swear to me that works, I still need proof. If the test is written after, during or before the code is, in my opinion, debatable and a matter of taste. But if is not properly tested is not finished, is not working code.
Very well said. Tests as evidence the code works is another great way to view them, since it gives an understandable measure of "ready or not ready" for everyone in the company. Leaving it to the engineer's word only risks damaging the relationship between departments when bugs inevitably slip through.
And I also like them to be a sort of documentation, I usually end up commenting more about the intent in the test than in the code; almos like a tour of the code in the tests.
Why just say what something do when you can show it and prove it in the tests; I'm starting with Rust and like Python you can add automagically some comments to the docs. Documenting and testing, two birds.
And you make sure is not stale, because those are tests that have to work.