Draft: TUnit Example

[thomhurst]

You mentioned last week that you wondered if TUnit was worth switching to - So thought I'd just do a draft branch to show you what Brighter would look like switched over.

Might be useful to see if test speeds improve or anything. I attempted to enable parallelisation by having tests use unique topic names, or queue names, etc. to better support test isolation. (Though I don't know if limited CI constraints will fight against more parallelisation!)

Don't feel obliged to adopt it or anything, just thought it'd be a bit more useful to see it in something more tangible.

[iancooper]

Oh, thanks for this. It's certainly more concrete. I need to let @lillo42 finish his generated tests, because it's hard to hit a moving target, but we could certainly think about this after that.

[thomhurst]

@iancooper — question about CompressPayloadTransformer sync vs async divergence I ran into while fixing the Core.Tests CI failures on this branch.

WrapAsync sets CharSet on the compressed ContentType (from the source message's charset, falling back to utf-8):

contentType.CharSet = message.Header.ContentType?.CharSet ?? CharacterEncoding.UTF8.FromCharacterEncoding();

Sync Wrap in the same file does not set CharSet. The two paths produce different headers for the same input.

The compressed payload is binary (stored as CharacterEncoding.Raw), and application/gzip / application/deflate / application/br have no registered charset parameter per IANA, so attaching one to the compressed ContentType looks semantically wrong. The original content type (with charset) is already preserved in ORIGINAL_CONTENTTYPE_HEADER for the unwrap side.

This was invisible until commit c76d53c switched a sync-origin test from Wrap → WrapAsync, exposing the mismatch (the existing CompressLargePayloadTests assertions expected no charset; the separate AsyncCompressLargePayloadTests was written against the async-with-charset behaviour). My fix removed the charset line in WrapAsync to match Wrap, and updated the duplicate async test file accordingly.

Two reasonable directions here — which do you want?

1. Keep my change: sync and async both omit charset on the compressed ContentType (what's on the branch now). Semantically correct per IANA, but a behaviour change for consumers relying on the current async output.
2. Revert and do the opposite: update sync Wrap to also set CharSet. Preserves existing async output, but bakes in the meaningless-charset-on-binary behaviour in both paths.

Happy to flip to (2) if you'd rather preserve the existing on-the-wire format.

[thomhurst]

Also noticed that emitted spans may have incorrect durations:

[codescene-delta-analysis]

Code Health Improved (1 files improve in Code Health)

Gates Failed
Prevent hotspot decline (1 hotspot with Low Cohesion)
Enforce critical code health rules (1 file with Low Cohesion)
Enforce advisory code health rules (1 file with Code Duplication)

Gates Passed
1 Quality Gates Passed

See analysis details in CodeScene

Reason for failure

Prevent hotspot decline	Violations	Code Health Impact
RedisMessageConsumer.cs	1 rule in this hotspot	6.72 → 6.33	Suppress

Enforce critical code health rules	Violations	Code Health Impact
RedisMessageConsumer.cs	1 critical rule	6.72 → 6.33	Suppress

Enforce advisory code health rules	Violations	Code Health Impact
CompressPayloadTransformer.cs	1 advisory rule	8.82 → 8.55	Suppress

View Improvements

File	Code Health Impact	Categories Improved
RedisMessageProducer.cs	9.39 → 10.00	Code Duplication

Quality Gate Profile: Clean Code Collective
Install CodeScene MCP: safeguard and uplift AI-generated code. Catch issues early with our IDE extension and CLI tool.