Skip to content

Publish StrongTypes.Generators NuGet package #13

@KaliCZ

Description

@KaliCZ

Goal

Publish a second NuGet package — Kalicz.StrongTypes.Generators — that ships the FsCheck arbitraries we already maintain for our own test suite, so anyone using Kalicz.StrongTypes in their project can reuse the same generators in their test suite.

Rationale

Every consumer of a strong-typed value like NonEmptyString will, at some point, want to write a property test against code that takes one. Without a published generator they have to roll their own — re-deriving the filtering rules we already encode (e.g. "non-null, non-whitespace") and probably weighting branches differently from ours. Shipping the arbitraries as a companion package removes that friction and keeps the testing story consistent across users.

Current state

Our own arbitraries live in src/StrongTypes.Tests/Generators.cs in the test project. Today it holds only NullableNonEmptyString, but we expect the list to grow alongside the library rewrite.

Rough work outline

  • Add a new project src/StrongTypes.Generators/StrongTypes.Generators.csproj.
    • Targets net10.0, LangVersion 14.0, TreatWarningsAsErrors=true to match the main library.
    • PackageId = Kalicz.StrongTypes.Generators.
    • Depends on Kalicz.StrongTypes (same version) and FsCheck.Xunit.v3 (or just FsCheck — decide whether we ship xunit-specific attributes or just raw arbitraries).
  • Move the arbitraries out of the test project into the new library project. The test project then consumes them via a project reference and registers them with [Properties(Arbitrary = new[] { typeof(Generators) })] the same way consumers would.
  • Add the new project to StrongTypes.slnx.
  • Update the CI workflow's pack step to build both packages and upload both artifacts.

Open questions

  • Namespace for the shipped class — probably StrongTypes.Generators, but confirm it doesn't shadow any existing type from the main assembly (we already hit a similar collision with Try).
  • Do we ship FsCheck-specific types (Arbitrary<T>, Gen<T>) directly, or also expose framework-agnostic raw predicates that can be adapted to other property-test frameworks? (Starting with FsCheck only is fine — can always add later.)
  • Versioning strategy — does the Generators package version lock-step with Kalicz.StrongTypes, or float independently?

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions