Welcome Guest! To enable all features please Login or Register.

Notification

Icon
Error

Running tests on code using DelegateCompiler library
bstenzel
#1 Posted : Tuesday, May 17, 2016 7:22:36 AM(UTC)
Rank: Newbie

Groups: Registered
Joined: 11/6/2015(UTC)
Posts: 5

Thanks: 2 times
Was thanked: 2 time(s) in 2 post(s)
I'm using DelegateDecompiler to implement filtering on the db on computed properties. A simple test case:

Code:
using System.Linq;

using DelegateDecompiler;

using NUnit.Framework;

public class Person
{
	public string LastName { get; set; }

	public string FirstName { get; set; }

	[Computed]
	public string FullName
	{
		get
		{
			if (this.FirstName != null)
			{
				return this.FirstName + " " + this.LastName;
			}
			return this.LastName;
		}
	}
}

[TestFixture]
public class RepoTests
{
	[Test]
	public void TestDecompile()
	{
		Person[] persons = {
							  new Person { LastName = "Doe", FirstName = "John" },
							  new Person { LastName = "Dickerson" }
						  };

		Assert.DoesNotThrow(() => persons.AsQueryable()
									.Where(p => p.FullName.Contains("Doe"))
									.Decompile()
									.ToArray());
	}
}


Using e.g. the ReSharper test runner this test passes, but in NCrunch it fails with an InvalidOperationException with the message 'No coercion operator is defined between the types "System.Int32" and "System.Int32&." at System.Linq.Expressions.Expression.GetUserDefinedCoercionOrThrow. I'm baffled to be honest. No idea where the int is coming from, much less the nullable int. I tried to check out DelegateCompiler as a sub dependency in a test project to debug through it, but I didn't manage to get it to compile in NCrunch.

Similar code that actually queries a database also runs, so I assume DelegateDecompiler is not at fault here. It does reverse-engineer expressions from generated IL code, though, and as far as I am aware NCrunch is pretty special (also extremely fast) as it uses its own builds. I guess that's somehow related to the issue.

Any input on how to get this to run would be appreciated.
Remco
#2 Posted : Tuesday, May 17, 2016 9:41:21 AM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 7,145

Thanks: 959 times
Was thanked: 1290 time(s) in 1196 post(s)
Hi, thanks for sharing this issue.

I don't have any firsthand experience with DelegateDecompiler, but based on what you've described, it looks as though this tool is making use of an IL-analysis step, either inside the build process for your project or possibly at run time.

NCrunch collects its code coverage and performance data from your code by instrumenting it at build time. Basically, it picks up the .DLL after the compiler has built it, and adds a whole range of additional IL instructions that enable it to track the way your code behaves under execution. The injected IL is designed as much as possible not to change the behaviour of your code in any way, but it does still physically change the code. I don't doubt that the DelegateDecompiler tool is picking up NCrunch's instrumentation and not making sense of it.

There isn't really any way for NCrunch to internally handle a situation like this, as it has no power over tools that disassemble instrumented code. There are two ways you can work around this problem:

1. Suppress NCrunch's instrumentation for the decompiled methods using code coverage suppression comments. This will allow you to select targeted areas of your code that you don't want to have instrumented, so that they don't interefere with DelegateDecompiler.

2. Turn off NCrunch's instrumentation for the projects involved using the instrument output assembly project-level configuration setting.

Note that both of the above workarounds will result in the loss of code coverage data collected by NCrunch.
2 users thanked Remco for this useful post.
bstenzel on 5/17/2016(UTC), samholder on 5/17/2016(UTC)
bstenzel
#3 Posted : Tuesday, May 17, 2016 11:16:42 AM(UTC)
Rank: Newbie

Groups: Registered
Joined: 11/6/2015(UTC)
Posts: 5

Thanks: 2 times
Was thanked: 2 time(s) in 2 post(s)
Thanks for your quick reply. Again you're spot-on. Fortunately it was enough to disable instrumentation on our project for the db entities, so we still have coverage data for everything containing actual business logic.

Thanks for a great tool and great support.
1 user thanked bstenzel for this useful post.
Remco on 5/17/2016(UTC)
Users browsing this topic
Guest
Forum Jump  
You cannot post new topics in this forum.
You cannot reply to topics in this forum.
You cannot delete your posts in this forum.
You cannot edit your posts in this forum.
You cannot create polls in this forum.
You cannot vote in polls in this forum.

YAF | YAF © 2003-2011, Yet Another Forum.NET
This page was generated in 0.031 seconds.
Trial NCrunch
Take NCrunch for a spin
Do your fingers a favour and supercharge your testing workflow
Free Download