Bootstrap Hedgehog

I think it would be a good idea to use the most recent stable version of Hedgehog to test the next/unstable version. Having property tests for Hedgehog itself would make the codebase much stronger (I realize we already use the current version for some tests), but I don't think using the unstable version to test itself is a good idea.

I'm also open to using another PBT library (FsCheck, etc) for this purpose, however I think it would be neat to use our own library.

[TysonMN]

I really like this idea, but I don't know how to bootstrap in a compiled language. Here is a post by Mark Seemann with someone discussion on this topic.

[moodmosaic]

I'd bootstrap in (kind of ) the same way as F# compiler bootstraps; in our case the latest stable major release can be used to build a "proto" Hedgehog assembly.

[TysonMN]

Won't there be a name conflict among DLLs (two wanting to be called Hedgehog)?

[moodmosaic]

Perhaps there can always be a pre-compiled Hedgehog-proto.dll (that we can trust, e.g. knowing its SHA256).

[TysonMN]

I hope I am wrong, because I am very interested in getting this to work.

Another issue for sure would be namespace collisions when we try and test ourselves 😅, this will have to be looked into. Right now, the only thing I can think of is changing the namespace based on some #pragma but this could get nasty and difficult to maintain.

[dharmaturtle]

Diving into implementation, this SO answer suggests using extern alias. Unfortunately, F# doesn't support this. The mentioned workaround of "A C# shim project..." may not work, according to this SO comment:

it's not possible to "launder" the alias through C# - it will be local to the C# project in which the alias is defined. But you can expose the functionality to F# through C# wrapper classes.

If we go down this route, we may have to do the bootstrapping in Hedgehog.Linq.Tests.

Diving into implementation, this SO answer suggests using extern alias. Unfortunately, F# doesn't support this. The mentioned workaround of "A C# shim project..." may not work, according to this SO comment:

I never knew about this feature, interesting!

If we go down this route, we may have to do the bootstrapping in Hedgehog.Linq.Tests.

Are you suggesting that we would use the Hedgehog.Linq interface and write the tests in C#? That's less than ideal, but it may be a decent starting point. My only concern is that the current C# extension for VSCode doesn't play well with F# projects, specifically I don't get any autocomplete from Hedgehog.Linq.Tests for any code referenced by Hedgehog.fsproj.

[dharmaturtle]

That's less than ideal

Yep... at least it (necessarily) improves test coverage.

I don't get any autocomplete from Hedgehog.Linq.Tests for any code referenced by Hedgehog.fsproj

I believe we would be referencing an old version of Hedgehog (e.g. 0.10), possibly via Nuget.

To float another idea, during a release, we could run a script that changes all the namespaces to include the version (e.g. Hedgehog_proto_0_11), publishes it to Nuget, then unlists it. (You can't delete a package off Nuget.) I currently don't see a way to unlist a package via cmdline... but it's a pretty small thing?

I don't get any autocomplete from Hedgehog.Linq.Tests for any code referenced by Hedgehog.fsproj

I believe we would be referencing an old version of Hedgehog (e.g. 0.10), possibly via Nuget.

The stuff from nuget would be fine, but the code we're testing wouldn't show up at all. This is a minor issue that shouldn't dictate our solution, but it's something to note.

To float another idea, during a release, we could run a script that changes all the namespaces to include the version (e.g. Hedgehog_proto_0_11), publishes it to Nuget, then unlists it. (You can't delete a package off Nuget.) I currently don't see a way to unlist a package via cmdline... but it's a pretty small thing?

I was actually considering pulling the code for a release from github and running sed -i /namespace Hedgehog/namespace Hedgehog.Latest/ or something along those lines.. 😅

[TysonMN]

[...] publishes it to Nuget [...]

GitHub can host NuGet packages within each repository, so we could host the NuGet packages there.