Supported way to reset the per-type business-rule cache (for test isolation)?

[gem4511]

CSLA caches a type's business rules in a process-global static (BusinessRuleManager), populated once via AddBusinessRules — exactly right for production. But for test isolation it's sometimes necessary to reset that cache between tests, so AddBusinessRules re-runs against fresh state.

The concrete case that brought me here is mutation testing (Stryker.NET). Because the rule cache outlives a single test, a mutation inside AddBusinessRules gets masked by a neighbor's cached registration, and per-mutant verdicts become non-reproducible. On a real CSLA business-object suite this was dramatic: run-to-run ~92% survivor-set churn at default settings. Clearing CSLA's per-type rule cache before each test fixed it completely — byte-identical, 0%-churn runs. The Stryker maintainer's own conclusion on the thread was that per-test cache clearing is the right mitigation ("resetting cache before each test is always important"): stryker-mutator/stryker-net#3742.

Today the only way I've found to do this is reflection into BusinessRuleManager._perTypeRules, which is brittle — and its shape even differs by target framework / AssemblyLoadContext support, so the reflection has to account for both. I did notice there's already an internal CleanupRulesForType(Type), so the eviction logic exists.

Would you consider a supported way to reset the rule cache for test scenarios? Something like a public BusinessRules.ClearRuleCache() (all types) and/or exposing per-type cleanup. It would help anyone isolating CSLA tests — parallelism, test independence, mutation testing — without reaching into internals. Happy to open a PR if you're open to it and point me at the shape you'd prefer.

[rockfordlhotka]

Yes, I would consider this.

There is (or used to be) an open issue to add a Csla.Testing project that would include unit test helper types.

#1225

I see I closed it - but still, the concept is totally valid.

The idea would be to have that project use internal methods or reflection to wrap complexity like you are talking about - so we don't open the API for non-testing scenarios, but do make it stable and maintainable for testing scenarios.

I'd love to have a PR for this!

[gem4511]

Thanks Rocky — happy to take this on. I pulled #1225 and the current source to ground it (via Claude Code, Opus 4.8).

Two things I noticed that shape the scope:

1. RuleContext already has a public testing ctor (the (ApplicationContext, Action<IRuleContext> completeHandler, rule, target, inputPropertyValues, mode) one). So the remaining gap from Consider a helper method to execute/test rules #1225 is really the ergonomics: hiding the sync-vs-async Execute/ExecuteAsync fork, building the input-value dictionary, wiring completeHandler to capture Results, and awaiting. I'd wrap that in a small fluent RuleTester returning a plain result object (broken rules + out-values) — no new public API on Csla itself, just the new Csla.Testing package sitting on top.

2. A second helper I'd love to include, if you're open to it: a rule-cache reset for test isolation. BusinessRuleManager.CleanupRulesForType(Type) already does exactly what's needed, but it's internal. I hit this hard doing mutation testing — the process-wide per-type rule cache leaks state between concurrently-run mutants and produces false "killed" results (repro'd it against mtp; happy to share). Exposing that one internal via [InternalsVisibleTo("Csla.Testing")] keeps it out of the production API exactly as you described, while giving test code a stable RuleCache.Reset<T>().

Before I open a PR, two decisions so I build it the way you want:

• Internal access: [InternalsVisibleTo("Csla.Testing")] (my preference — stable, refactor-safe) vs. reflection?
• Assertion-agnostic: I'd have the helpers return plain result objects with no dependency on any test/assert framework, so xUnit/NUnit/MSTest/FluentAssertions users all consume them. Sound right?

I'll match Csla's multitargeting and keep PR #1 to just these two helpers (rule execution + cache reset); BO-tree factories etc. can be follow-ups. Want me to reopen #1225 as the tracking issue or start a fresh one?

[rockfordlhotka]

Yes, I think 'InternalsVisibleTo' is the right answer.

Not tying the code to any particular test framework also makes sense. People use a lot of different frameworks, and we should continue to enable that.

[rockfordlhotka]

@gem4511 I'll need a contributor agreement from you so I can invite you to the repo.

[gem4511]

Hello Rocky, I've downloaded the pdf. Would you want it printed, signed and mailed. Or would a marked up emailed pdf do the job? I have enjoyed so many "Csla cookies" for so many years, I look forward to putting a cookie back in the jar.

…

On 08/07/2026 12:41 PM CDT Rockford Lhotka ***@***.***> wrote: @gem4511 https://github.com/gem4511 I'll need a contributor agreement from you so I can invite you to the repo. — Reply to this email directly, view it on GitHub #4875?email_source=notifications&email_token=CDXC6QERYMFGFZD5F6J4NGT5IYIDFA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCNZZGM3DKNZTUZZGKYLTN5XKO3LFNZ2GS33OUVSXMZLOOSWGM33PORSXEX3DNRUWG2Y#discussioncomment-17936573, or unsubscribe https://github.com/notifications/unsubscribe-auth/CDXC6QCE5TZX56JBJBPKXED5IYIDFAVCNFSNUABGKJSXA33TNF2G64TZHM4DAOBVG42DSO2ENFZWG5LTONUW63R3GEYDKMJTGE4TNILWAI. Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS https://github.com/notifications/mobile/ios/CDXC6QDOQYCW6KXJ4DWJYOD5IYIDFA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCNZZGM3DKNZTUZZGKYLTN5XKO3LFNZ2GS33OUVSXMZLOOSVGM33PORSXEX3JN5ZQ and Android https://github.com/notifications/mobile/android/CDXC6QDN5OKUR2FPWG4L6BD5IYIDFA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCNZZGM3DKNZTUZZGKYLTN5XKO3LFNZ2GS33OUVSXMZLOOSXGM33PORSXEX3BNZSHE33JMQ. Download it today! You are receiving this because you were mentioned.Message ID: ***@***.***>