I know you like TDD so I wrote a library to test the code that tests your code :)

Isn't that dangerous? I heard Skynet was not a fan of Homo Sapiens?

I think you (or I) might be missing the point of 100% line coverage. I want all the files to be loaded and all lines to be executed to be sure that there are no parse or runtime fatal errors. That doesn't prevent or replace writing correct tests that actually test functionality. But I don't want things like exception handlers to be left untested just because they're not a part of the business logic.

Mutually exclusive goals ;). My concern is assuming that one (the files are executed) is equated with the other (the code is tested) all because we only this one single metric doing the rounds in connection with the concept of "test quality". Line coverage doesn't necessarily even meet your goal - look at the if statement example - what if that had four terms and only one were executed? What if one of those terms, not exercised, calls a method on a var, and the var ends up being null? A relatively common error we all see at times. We need both - Code Coverage to check execution time issues and Mutation Testing to monitor our collection of tests/specs/features.

Of course, I'm not against mutation testing as an extra layer of protection, and we also do Behat test to cover things that aren't covered by unit tests (like controllers). What I'm saying is that line coverage has its uses - loads and executes all the code, shows which classes were not tested yet (when not doing TDD, which I really don't like), but you're right that it's not enough, just like mutation tests by themselves are not enough.