What to do when project coding standards conflicts with unit test code coverage?

Question

I'm working on a personal project for the learning experience, and also at the same time to implement a decent body of code. Part of this education, and making it a decent body of code, is unit testing. I have recently dived into PHPUnit and its code-coverage tools.

I have encountered a situation with a particular implementation where the coding standard used causes code-coverage to be lost. In this particular instance breaking the coding standard used causes a jump from 88% to 94% in code-coverage.

In a method I have 2 lines that look like the following

    // .. some data validation stuff
    trigger_error('Error validating the stuff', E_USER_WARNING);
}

The data validation and the stuff isn't important here, the } is. Right now when the unit test goes over this line of code a PHPUnit_Framework_Error is thrown on the line before the }, since the code never actually continues on to the end of the brace this line is never captured by code coverage.

If I do

    // .. some data validation stuff
    trigger_error('Error validating the stuff', E_USER_WARNING);}

I get a 6% jump in code coverage. I've tried setting PHPUnit_Framework_Error_Warning::$enabled to false but then I get an ugly, expected, error message in my terminal, since I want this project to eventually be used by people other than myself error messages on unit tests are unacceptable. In addition, I really would like for my coding styles to be implemented consistently. The code-style violation would likely jump out upon further perusals of the code, meaning I'd also have to add a dreaded comment explaining why the braces were moved...likely in multiple places.

I guess my question(s) are:

1. Is there a setting for PHPUnit that would allow the 1TBS to be used and still get covered by a test throwing an exception, or triggering an error, directly before a }?
2. Is it more important to follow the coding standard or get a boost in code-coverage? (Although the boost is really just the interpreter going over an extra })

Answer 1

Don't be obsessed with a number. You know that the numbers being reported are false and that you have more coverage than is being reported so why worry about it? It is more important that your tests cover all meaningful code than you achieve 100% code coverage.

If you feel the coding standard is important, and this one looks to be, then don't sacrifice readability for a number.