IMHO it is a very useful feature. It can be abused, true, but it also helps to automate some of the more mundane tests.
It might be useful to rename the tool from 'Smart Unit Tests' to 'Infer Unit Tests':
it changes adjective into a verb i.e. meaningless and somewhat misleading description into a very descriptive action
it shows better the true nature of the feature, after all PEX does exactly that - it infers inputs
It would be great if this feature could use information contained in Code Contracts as they provide an additional information about the requirements. I use Code Contracts whenever I can in all my new code and it would be fantastic if at some point Visual Studio would just pick this information up and helped me with unit testing.
spivonious is right, this was all basics - nothing new here, really.
If a developer does not know about locks/deadlocks etc. then I'm sorry to say, but he/she is just a poor developer. This is first year's knowledge on any decent university, no major degree required. This story was good maybe for Channel8, not 9.
I can't say for all the niners, but I personally feel that we should focus on specialized tools that assist in debugging concurrent programs, rather than stating the obvious about problems in parallel programming.
I supprot Johannes in that unordered results should be the default.
TPL and PLINQ should abstract away implementation details of parallel programming (as they do), but shouln't abstract the notion of parallel computing, which in its nature is unordered.
Nobody complains about SQL not preserving results ordering by default. SQL is set based in terms of data, and parallel computing is in a way set based in terms of Tasks. We shouldn't fool developers into thinking that parallel programming is the same as sequential
programming, because ideas behind them are quite different and developers need to be be aware of that fact.