xunit example

gistfile1.txt

A profiler can quite easily find the constructor call to default constructor on this code:
[Fact]
public void ModestCreatesParameterWithBlah(){
   var p = new MultiOrderedConstructorType();
   p.Number = ...;
   Assert.AreEqual(0, p.Number);
}

but on this it is created outside the scope of the test (its done internally by xunit)

[Theory, AutoData]
public void ModestCreatesParameterWithBlah([modest] MultiOrderedConstructorType x) {
   Assert.AreEqual(0, x.Number);
}

in the first example the call to the constructor when looking at the current stack is under the context of a test. the second is not.


How would a coverage tool know to associate the constructor called before the test internally to xunit to the Theory?

If I were just giving the callchains so your plugin could decide necessarily the other calls there will be in the chain (as of now what is in the chain is what you will see). And no you aren't always only interested only in what happens in your code (I can give at a minimum 5 valid use cases where people want to see other code). So I would also need to give you some way of saying "these aren't important even though we said they are they are only needed for the plugin to decide where start". Then as well we can run into problems with using the profiler on the runner's own code base (it wouldn't profile correctly, though this is admittedly a minor issue). My main worry though is that these seem to not only be method scoped, they are also fixture scoped from this conversation. How many other scopings are there (more importantly how stable are they?). It would be absolute hell if these changed from version to version of the runner. I will go research how some of the other tools are handling these cases. Greg

On Tue, Apr 3, 2012 at 10:29 AM, sgryt < ***@***.*** > wrote: I'm 'only' interested in profiler coverage of my own code - and I'm not entirely sure I understand your question wrt the sequence diagram? --- Reply to this email directly or view it on GitHub: https://gist.github.com/2290767

## Le doute n'est pas une condition agrable, mais la certitude est absurde.

I haven't heard of any other unit testing frameworks that can be customized wrt object construction (but @ploeh can probably say more about that) for test method parameters, but that is probably just due to the fact that I haven't done enough research. I'll be very interested in hearing about your findings, though.

My personal primary interest is to have the profiling test coverage counters be as inclusive as possible - for my code. I'm curious as to why you think I would be interested in test coverage for code that is not under my control, or the intricate details as of how xUnit internals wire stuff together? It doesn't matter that much to me to see a connected call chain containing both the object construction and the test method - I'm just really keen on having the AWESOME in-your-face visibility of test coverage for the largest possible part of my codebase.

I certainly understand your worries - that's why I propose that MM users take that part of the responsibility themselves - with a plugin implemetation of their own, targeted at a specific unit testing framework.