refactor: convert 15 manual assertions to [GenerateAssertion]

[thomhurst]

Summary

• Replaces 15 manually-written Assertion<T> classes with [GenerateAssertion]-decorated static methods, eliminating ~500 lines of boilerplate
• The source generator auto-creates both the assertion classes and IAssertionSource<T> extension methods
• All assertion behavior is preserved (same logic, expectation messages, and failure messages)

Converted assertions

Group	Methods	Pattern
Comparison	IsGreaterThan, IsGreaterThanOrEqualTo, IsLessThan, IsLessThanOrEqualTo	AssertionResult return, IComparable<TValue> constraint
Null	IsNull	bool + InlineMethodBody (null must pass, not fail)
Reference	IsSameReferenceAs, IsNotSameReferenceAs	bool + InlineMethodBody (ReferenceEquals(null, null) must return true)
String	IsEmpty, IsNotEmpty	AssertionResult return
Enum	HasFlag, DoesNotHaveFlag, HasSameNameAs, DoesNotHaveSameNameAs, HasSameValueAs, DoesNotHaveSameValueAs	AssertionResult return, struct, Enum constraint

Minor behavioral changes (acceptable)

Change	Old	New
Exception message format	"threw {Name}"	"threw {FullName}"
Null message (AssertionResult group)	"received null" / "value was null"	"Actual value is null"
Failure message (bool+inline group)	"received {value}" / "received different references"	"found {value}"
Generated class names	e.g. GreaterThanAssertion<TValue>	e.g. TValue_IsGreaterThan_TValue_Assertion<TValue>
Class modifier	public class	public sealed class

Test plan

• TUnit.Assertions.Tests — 1813 tests pass
• TUnit.Assertions.SourceGenerator.Tests — 56 tests pass
• TUnit.Core.SourceGenerator.Tests — 114 tests pass (1 pre-existing skip)
• TUnit.PublicAPI — 3 tests pass (snapshots updated)
• No .received.txt files remaining

[claude]

Code Review

This is a solid architectural direction — using [GenerateAssertion] to eliminate boilerplate is exactly what the attribute was designed for, and removing ~500 lines of repetitive class definitions is a clear win. The approach is well-structured and well-tested. That said, there are a few issues worth addressing.

---

Issue 1: Generated class names pollute the public API (significant)

The generated names like TValue_IsGreaterThan_TValue_Assertion<TValue> are implementation details that have leaked into the public API surface. In AssertionExtensions.cs and CountWrapper.cs, these now appear as return types of public methods:

// Before — readable
public static GreaterThanAssertion<DateTime> IsAfter(...)
public static LessThanAssertion<int> LessThan(...)
public static GreaterThanAssertion<int> Positive()

// After — ugly
public static TValue_IsGreaterThan_TValue_Assertion<DateTime> IsAfter(...)
public static TValue_IsLessThan_TValue_Assertion<int> LessThan(...)
public static TValue_IsGreaterThan_TValue_Assertion<int> Positive()

End users hovering over these in IntelliSense will see the cryptic generated names. The old names like GreaterThanAssertion<T> were semantically meaningful and part of the intended public API. This is also reflected in the TUnit.PublicAPI snapshot changes — you're swapping readable type names for generated ones in the public contract.

Suggested approach: Either (a) ask the source generator team to support a ClassName parameter on [GenerateAssertion] to control the generated class name, or (b) add [Obsolete]-style type aliases for the old names if binary compatibility matters. Alternatively, consider whether these methods actually need to expose the concrete assertion type in their return signature, or whether they can return a base/interface type instead.

---

Issue 2: Null handling regression for comparison assertions (significant)

The old GreaterThanAssertion, LessThanAssertion, etc. had an explicit null guard:

// Old code
if (value == null)
{
    return Task.FromResult(AssertionResult.Failed("received null"));
}

The new generated code doesn't have this:

// New code — no null check
public static AssertionResult IsGreaterThan<TValue>(this TValue value, TValue minimum)
    where TValue : IComparable<TValue>
{
    return value.CompareTo(minimum) > 0  // 💥 NullReferenceException if value is null
        ? AssertionResult.Passed
        : AssertionResult.Failed($"received {value}");
}

Since TValue : IComparable<TValue> doesn't exclude reference types (e.g., string), a null value will throw NullReferenceException instead of producing a proper assertion failure. This is a behavioral regression for nullable reference types.

The test suite likely doesn't cover this case because existing tests pass, but it would affect users asserting on nullable string comparisons or other nullable comparable reference types.

---

Issue 3: Misleading error messages for IsEmpty/IsNotEmpty with null strings (moderate)

Old behavior:

• IsEmpty(null) → fails with "value was null" ✓ clear
• IsNotEmpty(null) → fails with "value was null" ✓ clear

New behavior:

public static AssertionResult IsEmpty(this string value)
{
    return value == string.Empty
        ? AssertionResult.Passed
        : AssertionResult.Failed($"received \"{value}\"");  // 🐛 null renders as ""
}

When value is null, the interpolation $"received \"{null}\"" renders as received "" — which looks identical to the empty-string case. A developer seeing this failure message would think the string was empty, not null. The same issue affects IsNotEmpty.

This is arguably worse than the "Actual value is null" message the PR mentions as an acceptable change, since it produces a misleading message rather than just a different one.

---

Minor observation: file-scoped access modifier usage

Using file on NullAssertionExtension and ReferenceAssertionExtensions for the InlineMethodBody = true cases is a nice touch — it correctly hides implementation details that users shouldn't call directly. The [EditorBrowsable(EditorBrowsableState.Never)] pattern used on the other extensions serves a similar purpose well.

---

Summary

Issue	Severity	Blocking?
Generated type names in public API	Significant	Worth discussing — may be acceptable tradeoff if source gen can't support custom names
Null regression for comparison assertions	Significant	Yes — behavioral regression
Misleading null message for IsEmpty/IsNotEmpty	Moderate	Yes — produces actively confusing output

The refactor goal is excellent and the structure is clean. The main asks are: restore explicit null handling for the comparison and string assertions, and ideally find a way to control the generated class names to preserve the public API readability.