So this just crossed my radar: http://lambda-the-ultimate.org/node/4945

Has some interesting ideas that should be straight forward to implement in NCrunch

I particularly liked the idea of attaching structured trace logs as line annotations

Would be awesome to replace trace output from my acceptance tests with something easier to filter and navigate.

I'm already using NCrunch in the way they describe to see coverage when debugging a single test. The indications of where time is spent is also very appreciated. Adding a simple counter as in http://alltom.com/pages/...14/images/slide.010.jpg could be interesting to see if it adds any value. If running multiple tests I guess a tooltip or such could break it down into individual tests.

Just now I was thinking of how to get this information recorded for a manual execution. But I guess that's simply a matter of launching "main" from an otherwise ignored test.


For the structured trace as in http://alltom.com/pages/...14/images/slide.013.jpg I was thinking that instead of, as in their case, putting everything in one output window you would navigate by using the src lines as bookmarks into the call graph.

One version of this might be to add 'probes' which NCrunch would add to the code and record, so you could examine recorded values much as you would in the debugger when execution is halted, only with the option to navigate in time. Adding a probe would, as they say, be similar to adding a Debug.WriteLine or such, only it would only be a click, and would require a recompilation. But I guess I would like it to end up in version control, and possible usable outside of NCrunch.

I guess I was a bit inspired by http://blogs.msdn.com/b/...g-semantic-logging.aspx and the possibility to use it as (- BROKEN LINK -)

I do think that a UI for navigating and visualising execution traces is probably out of scope for NCrunch, but could certainly be made as a separate product with tight integration.

Besides execution counts I don't have any direct ideas for passive presentation.
Possibly some kind of code map with a heat signature. Not sure how useful that would be though.
(In my dreams the solution explorer, or files for that matter, has been replaced with a 3D-rendering of the application, 2D for module layouts, and 1D for layer separations, such that dataflow can be visualized as connections between layers, making an obvious place to hook in various visualization probes for debugging)


In a recent WPF application we developed I depended mostly on logging for post-execution alaysis, as you say. Which is a nice way to discover such oddities as code being executed more than necessary. Here are some of the strategies I've adopted to make this effective

* Add tracing to both Get and Set implementation of properties (using a common base class capturing [CallerMemberName])
* Add tracing to events and Rx.OnNext (this could probably be done as a custom scheduler)
* Add visible headers (lots of whitespace) to the trace for significant events, mostly top level calls (SpecFlow step -> PageObject method called -> ICommand executed)
* Add a simple instance id (static int++ on new) to use as prefix for tracing (ClassName + instanceid + method called + arguments)
- This is also used to trace lifecycle events such as new and dispose. I had the finalizer report undisposed instance to track down leaks. Had to force a bunch of GC calls and such at the end of each test to not have those reported in the wrong test though.
* Prefix all traces with threadid
* Prefix all traces with time (offset from start is enough, but implemented it in such a way that it usually measures offset from NCrunhc process start, which is less useful)
- I find this is mostly used to find performance issues, so it would be much better to have this presented as execution time in the usual profiler tree

In the end it's lots of data to wade through, so some means of selecting interesting subsets for a particular debugging sessions would be useful. I guess the common approach is to use a combination of trace level and logger instance to achieve this, didn't get around to it in this project. One coverage filter that could be interesting would be to only show coverage reachable from a particular method, just like you can show only coverage for a particular test. However in an age of async, TPL, Rx and event handler the notion of "reachable from a method" might be as straight forward as keeping track of the stack.

WRT performance I don't think a stack trace for each call is really necessary or even useful for that matter. Instead it might be better to keep track of your own execution graph and just add nodes to the graph as explicitly requested by the programmer. Not sure how that could be achieved though, CorrelationManager from System.Diagnostics?

WRT to capturing traces I resorted to ToString() overrides to get useful data. But I guess with something like semantic logging you'd rather extract raw data instead, which still has to be persistable though. Maybe the programmer could supply a Func<T,object> to the tracing definition as needed.




Another idea that just popped into my head is to attach test case data to tested units. Let's say you write a method int CalculateSomething(int arg1, int arg2), besides displaying that the method is covered by a test, how about folding out actual test data in the editor? Some options:
* A table of arguments and expected results and the actual result
* A REPL worksheeet such as the one from Scala https://github.com/scala...et/wiki/Getting-Started or along the lines of Linq pad
* Visualization such as http://conal.net/papers/Eros/