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.
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.