Back in my last job, management tried to get automated standards for code coverage. This led to people writing unit tests that looked like:

  //implementation
  var CONSTANTS = {
    RED : "red"
  }:

  //test
  test(function () {
    assert.strictEqual(CONSTANTS.RED, "red");
  });

I spent a lot of time arguing (unsuccessfully) that these kinds of tests accomplished literally nothing. I heard everything from, "well, this lets someone know that the constant shouldn't change" to "well, writing it twice will encourage programmers to be more careful."

The worst was that people started doing it with translation strings. So we'd send a config file to the doc team, they'd rephrase something to be clearer, or remove a misspelling, and suddenly tests are failing and the translation string can't be committed until the next day. We had a release build delayed over this once.

Meanwhile, because the coverage report is already showing the code path that displays the string as green, nobody has written tests to figure out if the dialog containing the string actually shows up on screen.

Sometimes I feel like the entire concept of code coverage was just a mistake ;)