A Tech Lead in my team said:
We're going to use sonar on our (500KLoc) codebase so that everytime you do a commit, it will check the classes you've touched against the coverage goals. If you don't meet the coverage goals for your commit, the build will break.
Another developer responded:
No that has no value. The classes were written against a specification with particular test scenarios in mind. It's not possible to discover what those test scenarios were from the code. You can't write a useful JUnit test on legacy code because you don't understand the original intent.
The first tech lead responded:
You can infer the requirements from the codebase, and the user experience of the software. All the JUnit test does, even if it does capture the original test scenarios, is demonstrate that a working path exists in the code. You can't say that JUnit tests represent a proof, but providing coverage of the code is extremely valuable.
My question is: When writing a JUnit test for non-covered legacy code - how important is it to understand the original scenarios?
Note that this is different to the linked question because it is about intent or inferred requirements as input to the JUnit tests on the legacy code.