Description

Code Digger is a lightweight version of Pex that allows you to explore public .NET methods in Portable Libraries directly from the Visual Studio 2012 code editor. It's a highly simplified and nifty way to leverage the power of Pex and Z3, one of the world's fastest constraint solvers.

So, how does Code Digger actually work? Why the PCL requirement? What happens when you click on the magic button, Alice?

Nikolai Tillmann and Peli de Halleux, software developers extraordinaire on MSR's RiSE team, join us again to dig into Code Digger in a casual setting (Nikolai's office, so native habitat). There is lots of geeking out at the whiteboard, of course. There is also a brief demo at the end. Tune in.

The Discussion

its great that we finaly see a sign of life from what used to be pex..

But in its present form, code digger is not very useful.. limiting the exploration to portable libraries just makes no sense.. pex had no problem with regular libaries so why does code digger?

Also, pretty much all the features that made pex useful are stripped from code digger.. it makes very little sense (other than mabe from an economic perspective) since VS is well known to have excelent backwards compatibility for extensions. [even more so between vs2010 and sp1 and sp2]

I really appreciate the simplification of using this instead of full PEX. Great effort.

One think, I noticed that you need to add an exception or assert in the code under test.My feeling is that developer will never do that, and hence digger will not show the potential bug.

So the question is, is code digger meant to be used on a parameterized unit test rather than the actual code? Or the required additions are the appropriate way to write good code? and perhaps Code Digger should say it and refrain from creating the table.

The assumption that seemed apparent from comments in the video was that mobile apps are the main concern. Personally, I'm not writing mobile apps. Even when I'm writing a reusable library, I'm generally not targeting Windows Phone but rather just ".NET".

For that reason alone it'd be good to see a more complete version that is closer to the original PEX, but simpler to use and more robust.

Another reason is that I still have to deal with .NET 3.5 code, so having a version of this that works with .NET 3.5 (but in a VS2012 project) would be great.

@aljj: You don't actually need exceptions or asserts. Code Digger will try to create inputs that trigger each branch in your code. If your code can throw exception or contains assertions, then you just get more valuable feedback on how your code might fail.

@JohnLudlow: It's not just mobile code, but just consider the growing landscape of Windows Phone apps, Windows Store apps, desktop apps. Your best bet is to use Portable Class Libraries if you want to share code between all platforms. In any case, stay tuned for a full Pex release with more features!

no, i didn't but i have now. i think my comment is still valid though, i still do not see a good reason for limiting code digger to pcl.. most methods will be resonably pure anyway even if they are not in a portable library, also its not like pex crashed if it ran into a parser or some reflection, it just ran in to its depth/constraint limit, why cant code digger do the same?

Granted, i'm not even near as clever as the rise guys, but is there really no way to run into those constraint limits anyway?

it was heartening to hear that a complete version of pex was on its way, but i also remember getting involved in the pex community and evangilizing pex left and right during its first run only for the pex team to essencially turn its back on the community, first saying an update was coming "soon" then shutting down the forums and not updating the project page for like 2 years. Yes, that's a risk any early adopter/beta tester takes but it still sucks when it happens..

Pex is an awsome technology, there is nothing out there like it and it just be such a terrible shame if it fell into obscurity.