Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Test methods with FsCheck.Xunit.PropertyAttribute throws MissingMethodException in xUnit 2.9 #682

Open
erikljung opened this issue Aug 6, 2024 · 4 comments

Comments

@erikljung
Copy link

erikljung commented Aug 6, 2024

Methods which uses FsCheck.Xunit.PropertyAttribute, throws MissingMethodException in xUnit version 2.9 when having ITestOutputHelper as a ctor dependency. Removing the ctor seems to solve the problem. This error is not present in 2.8.1. FsCheck version used is 2.16.6.

Exception:

System.MissingMethodException
Constructor on type 'Repro.Tests1' not found.
   at System.RuntimeType.CreateInstanceImpl(BindingFlags bindingAttr, Binder binder, Object[] args, CultureInfo culture)
   at System.Activator.CreateInstance(Type type, Object[] args)
   at ReflectionAbstractionExtensions.<>c__DisplayClass0_0.<CreateTestClass>b__0() in /_/src/xunit.execution/Extensions/ReflectionAbstractionExtensions.cs:line 42
   at Xunit.Sdk.ExecutionTimer.Aggregate(Action action) in /_/src/xunit.execution/Sdk/Frameworks/ExecutionTimer.cs:line 31
   at ReflectionAbstractionExtensions.CreateTestClass(ITest test, Type testClassType, Object[] constructorArguments, IMessageBus messageBus, ExecutionTimer timer, CancellationTokenSource cancellationTokenSource) in /_/src/xunit.execution/Extensions/ReflectionAbstractionExtensions.cs:line 42
   at <StartupCode$FsCheck-Xunit>.$PropertyAttribute.testExec@212(PropertyTestCase this, IMessageBus messageBus, Object[] constructorArguments, CancellationTokenSource cancellationTokenSource, XunitTest test, RunSummary summary, TestOutputHelper outputHelper, Unit unitVar0)

Repro:

public class Tests1
{
	public Tests1( ITestOutputHelper output ) { }

	[Property]
	public void Throws_in_xUnit_2_9( int i )
	{
	}

	[Fact]
	public void Works_in_xUnit_2_9_and_2_8_1() { }
}

public class Tests2
{
	[Property]
	public void Works_in_xUnit_2_9( int i )
	{
	}
}

xunit/xunit#2996

@bartelink
Copy link
Contributor

I wonder does moving to FsCheck v3 rc3 make any difference?
If you look at recent discussions in the xunit repo (last few days), there is no binary compatibility guarantee within xuit v2 releases, and the looseness/tightness of the xunit dependency has had some adjustments in recent times (IIRC v3rc1 had a 2.4.x restriction that got relaxed)
If I needed to get this resolved fast, I'd try updating to xunit 2.9 in this repo, and potentially making a PR for fscheck.xunit to v3rc4 to target 2.9 if necessary (though ideally fscheck v3 would continue to work with xunit >= 2.4 as per https://www.nuget.org/packages/FsCheck.Xunit/3.0.0-rc3#dependencies-body-tab of course)

@erikljung
Copy link
Author

erikljung commented Aug 6, 2024

Unfortunately I don't have the time to upgrade the whole project to v3 right now. The quickest workaround is to downgrade xUnit to 2.8.1. Just FYI xunit/xunit#2996 (comment)

@bartelink
Copy link
Contributor

Fair enough; not doubting the facts, and it's great to have the issue logged and workaround noted. Just saying more than likely someone will need to do the legwork to:
a) validate and/or fix it for v3
b) consider fixing it for v2 (or pinning the requirements for xunit to < 2.9)
c) close the issue in xunit unless it's actually proven that there's something useful that can be done on that side

... and that I'd likely do the first step and then decide whether I want to do the second, or port my tests to V3 given it's pretty stable now.

(I'd also replied to your other issue that you linked)

@bradwilson
Copy link

This is the likely problem: xunit/xunit#2996 (comment)

I wonder does moving to FsCheck v3 rc3 make any difference?

We formalized the support for passing along Func<T> as an argument value for any T that we will unwrap later, so when v3 support is added, this would need to be fixed anyway if the current strategy of bypassing the existing test infrastructure is used. (Note: it's perfectly fine to bypass the existing test infrastructure, that's why we layer it like we do, so please don't read that as this library doing anything wrong. It's absolutely not. We changed something underneath without adequately considering what all the likely impacts would be.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants