[xilun0]

As for you comment, if I were in the mood for trolling I would say: likewise. If you introduce a static error in a file, hopefully a tool will detect it, and the sooner the better. That you can't even run any code in the file because it makes no sense any more won't prevent your unit tests from running on other files (or at least a subset) if your program has at least a semi-correct architecture. At this point you just have to use the diagnostic information the compiler gave up to fix the syntaxic/typing problem, instead of trying to fix it at a latter stage for a greater cost. There is absolutely no point in trying to test a program that statical analysis has proved to be wrong.

[Argorak]

In a theoretical sense: yes. But for practical reasons, I do not have one test per compilation unit, but multiple. Thats why I chose XUnit as an example: classes are groups of tests, while the actual tests are written in methods. So it makes sense to defer (or at least to be able to defer) "broken parts" to have a better understanding of how much is exactly broken. And "just have to use" is sometimes not that easy if for example your task is ripping out a whole subsystem and fitting a new one. You would really like to see progress there instead of "tiny feature Y is not provable by your compiler, so I won't tell you whether feature X,Z and B work". So I am interested in whether only a part of the compilation unit makes sense. Ruby does that: I can tell my test suite that I fully expect this test to be broken at the moment and that I want that reported. In Java, I'm lost until I satisfied the complainer - ehm - compiler.

Thats actually the reason why I know more then one Java and C shop that use Ruby/Python/similar for their test suite.