When will a download be available or did I miss where the download already exists?

Looks cool, I can't wait to play with it.

He's...he's... ALIIIIVE!!!

Hey Peli, looking forward to checking this out! Good to see you can finally talk about your work.

Fantastic concept, can't wait to try it out.
One point : when Pex auto-generates a unit test, does it (or could it be modified to) add an attribute linking it back to the method being tested? I find that in large projects it can be hard to find the unit tests for a specific method.

This looks very cool and eventhough there are other tools around which do more or less the same thing (not for .NET though) I wonder why Microsoft keeps publishing misleading/wrong information!!

"taking test-driven development to the next level" but TDD has NOTHING to do with automatic unit test generation, it's about design exploration. It's not about bugs and fix.

Keep up the good job and change the text on the homepage :-)

Jay -- the tool is currently avaible inside Microsoft only. I'm not qualified to tell you when it will be available to customers. If you make enough buzz about it....

Haaked -- feels good indeed.

Dr Herbie -- I'm not sure what you are looking for here. Pex does annotate the generated tests with several custom attributes to help people build tools on top of it (we also generate xml docs for humans). One of those attributes, provides information on the parameterized test that was used to generate the test. This information is used by Pex to do the bookeeping. If you could elaborate on the subject, we can always think about adding more attributes :)

Zio -- This is a comment that we have received from many TDD'ers. I think it is due to the misconception that Pex is *just* about generating tests. Probably our description of the tool does not really reflect what it's intention is.

We think that Pex does enable a new programming experience, which can be used in a different fashion. One of the advantages of Pex is that it gives you the 'next' unit test case (instead of you writing it). If you take a look at the screencast (I should probably explain what is does), you will see that :

- we write the (parameterized) test first: 'for any sring and chunk length, the concatanation of the chunks should be equal to the original string'.
- we use the test to drive the design of the chunker
- we start with a minimal implementation (Next() returns null)
- we verify that our test fails: pex generates 2 test cases for us, one that takes the null string (test passes), one that takes the empty string (test fails). In that sense, Pex generated the next failing unit test for us.
- we write a bit more code to have our failing unit test pass and run pex again...

I think this process qualifies as being TDD'ish.