What you want to test is the interface of your module to the rest of the application and whether it satisfies the published contract, and preferably if it handles weird cases correctly.
Those tests cannot be done by a tool.
I don't know what's a "module". If a module is a "small unit of code" (eg, a class), that's usually what you cover in your unit test.
You're criticising unit test for things that unit tests don't do.
I hate apples. They don't taste like pears.
A useful discussion on the terminology problem can be found here: http://c2.com/cgi/wiki?StandardDefinitionOfUnitTest
Most definitions define unit testing as testing the "smallest piece of code that can be tested in isolation". Then my criticism definitely applies.
And given my code reviews, it's obvious that the vast majority of programmers see unit testing as testing every individual function/method in isolation. This actually hides problems by increasing total source code (actual code and the tests + "compromises" for testability) and locks down internal structure of supposedly encapsulated logic. Both are very, very bad things.
It is designed to generate input for your code (the public surface by default) to determine whether it runs correctly. It can use code contract features in .Net to help inform whether your code is correct. It is great for finding those 'weird cases', and where you find a particularly interesting case, it is easy to add it as a test in your suite.
You can see it used (and play around yourself) through the browser here: http://www.pexforfun.com
Are you referring to something like globals?
One instance of namespacing I've found so far is line 118 in the Common/InputDataProvider.php
How does it handle that time has passed since the recording of the test?
I realize that this may be an issue with a poorly written method or un-anticipated side effects, but with legacy code, that is often what you have to deal with.
Cool stuff, though!
