I'm a pretty big fan of doctest for simplistic testing (as you mentioned, it's good for documentation so show a working example and simple edge case behavior) and having those tests integrated during builds. However for many testing scenarios (I largely deal with parallelizing and parsing) the amount of code around tests makes keeping them inline cumbersome to people trying to focus on the actual production code: By moving the test code to separate files you can separate production and test changes both during writing (it's harder to get confused about what's a test function and what's a production function) and during code review (it's easier to parse the behavior of the change, and then identify that the tests have been updated correctly). Additionally, depending on your language, if you have separate files you can decrease your release size by excluding tests from production pushes.
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'm a pretty big fan of
doctestfor simplistic testing (as you mentioned, it's good for documentation so show a working example and simple edge case behavior) and having those tests integrated during builds. However for many testing scenarios (I largely deal with parallelizing and parsing) the amount of code around tests makes keeping them inline cumbersome to people trying to focus on the actual production code: By moving the test code to separate files you can separate production and test changes both during writing (it's harder to get confused about what's a test function and what's a production function) and during code review (it's easier to parse the behavior of the change, and then identify that the tests have been updated correctly). Additionally, depending on your language, if you have separate files you can decrease your release size by excluding tests from production pushes.