Tests discovery stops working when defining FsCheck's generators of DateOnly

[arialdomartini]

I stumbled upon a weird behavior with Expecto and FsCheck
I'm not sure if it depends on one or the other, though.

TL;DR changing

let randomDate = Arb.toGen Arb.from<DateTime>

to

let randomDate = Arb.toGen Arb.from<DateOnly>

prevents Riders from discovering the Expecto tests.

I've got this dummy module:

module FSharpBits.PropertyBasedTesting.WithFsCheck.Puzzling

open FsCheck
open Expecto
open System

let randomDate = Arb.toGen Arb.from<DateTime>

[<Tests>]
let treeTests =
    test "just fail please"
        { Tests.failtest "I'm just failing" }

Notice how that randomDate is unused.

Tests are discovered with YoloDev.Expecto.TestSdk and by checking Enable VSTest adapters support, as per #326.

When randomDate generates a DateTime the test explorer shows:

When it is set to generate DateOnly instead of DateTime, all the Expecto tests, from all the modules, just stop being discovered:

The few tests still being discovered are the xUnit tests only.

Any idea how I could debug this weird behavior?

[farlee2121]

Hmm. The first thing I'd do is try to see if upstream steps are working.

In particular you could run the test project with dotnet run to see if Expecto alone is discovering tests. Then you can run with dotnet test to see if the transition from Execto to YoloDev/dotnet test is working correctly. If all of that is ok, then it's probably an issue in Rider that Jetbrains would need to fix.

[Numpsy]

fwiw, I just tried this directly from an Expecto command line test app, and got

Unhandled exception. System.TypeInitializationException: The type initializer for 'edt' threw an exception.
 ---> System.TypeInitializationException: The type initializer for '<StartupCode$edt>.$edt' threw an exception.
 ---> System.Exception: The type System.DateOnly is not handled automatically by FsCheck. Consider using another type or writing and registering a generator for it.
   at Microsoft.FSharp.Core.PrintfModule.PrintFormatToStringThenFail@1448.Invoke(String message)
   at FsCheck.ReflectArbitrary.reflectGenObj@162.Invoke(Type t)
   at FsCheck.Common.f@1[a,b](IDictionary`2 memo, FSharpFunc`2 f, a n, Unit _arg1)
   at FsCheck.Common.memoizeWith[a,b](IDictionary`2 memo, FSharpFunc`2 f, a n)
   at FsCheck.Common.memoize@22.Invoke(a n)
   at FsCheck.Arb.Derive@1326.get_Generator()
   at edt.staticInitialization@() in S:\DevTest\edt\Main.fs:line 8
   at <StartupCode$edt>.$edt..cctor()
   --- End of inner exception stack trace ---
   at edt..cctor() in S:\DevTest\edt\Main.fs:line 0
   --- End of inner exception stack trace ---
   at edt.main(String[] argv) in S:\DevTest\edt\Main.fs:line 19

Which sounds more like an FsCheck limitation than an Expecto problem.