Install
$ agentstack add skill-tairitsua-monica-monica-application-unit-testing ✓ scanned · ✓ verified, works with Claude Code, Cursor, and more.
Security review
✓ PassedNo issues found. Passed automated security review. · v0.1.0 How review works →
- ✓ Prompt-injection patterns
- ✓ Secret / credential exfiltration
- ✓ Dangerous shell & filesystem operations
- ✓ Untrusted network calls
- ✓ Known-malicious package signatures
What it can access
- ✓ Network access No
- ✓ Filesystem access No
- ✓ Shell / process execution No
- ✓ Environment & secrets No
- ✓ Dynamic code execution No
From automated source analysis of v0.1.0. “Used” means the capability is present in the source — more access means more to trust, not that it’s unsafe.
Verified badge
Passed review? Show it. Paste this badge into your README, it links to the public security report.
Reliability & compatibility
Declared compatibility
Compatibility is declared by the source manifest. End-to-end runtime verification is coming, see below.
We're building live execution health for every listing: tool-call success rate, median latency, uptime, and last-checked timestamps, measured, not self-reported. It isn't live yet, so we don't show numbers we can't stand behind.
How agent discovery & health will work →About
Monica Application Unit Testing
Use sociable application tests for Monica-based business services. Boot the real Monica module graph once per service test project, replace only external seams, and resolve handlers, domain services, repositories, and module registrations from DI.
When To Use
- Create a
Test.{ProductionProjectName}project for an application service. - Migrate old NUnit/xUnit2/Moq/scratch tests into the new
Test.*style. - Test command handlers, query handlers, domain services, repositories, and module/service registration in a Monica application.
- Decide whether a test should use
MonicaApplicationFixtureor the fast-pathApplicationServiceFixture. - Choose a database isolation strategy for application tests.
Workflow
- Read the service's startup path first. Identify its module startup type or service runner and the DbContexts it registers.
- Create one runnable test project per production project:
src/Tests/Test.{ProductionProjectName}for business solutions ortests/Test.Monica.{Project}for Monica framework projects.
{ProductionProjectName}is the exact.csprojfile stem of the primary project under test.- Examples:
UserService.API->Test.UserService.API;AlarmService.API->Test.AlarmService.API;MessageService.Domain->Test.MessageService.Domain. - Do not shorten or normalize suffixes.
Test.AlarmServiceis invalid when the production project isAlarmService.API.
- Add
CollectionFixtures/{Service}Collection.csand{Service}TestFixture.cs. The fixture should derive fromMonicaApplicationFixturewhen the service has a startup module. - Override fixture defaults only for boundaries:
- test databases
- distributed state
- event bus
- HTTP/RPC clients
- current user or tenant context
- Keep test folders aligned with production folders:
HandlersCommand,HandlersQuery,DomainServices,Repositories,Entities, andModules. - In each sociable test, start with
await using var scope = _app.NewScope(...), resolve the unit under test from the scope, passscope.CancellationToken, and assert public behavior plus observable side effects. - Run the target test project with Windows paths under WSL. Run a single
dotnet testprocess at a time.
Default Choice
Prefer MonicaApplicationFixture for application services because it catches real DI and module-wiring failures. Use ApplicationServiceFixture only for narrow fast-path handler tests where all collaborators are intentionally substituted and module boot would add noise.
Required Conventions
- Test project:
Test.{ProductionProjectName}for business services,Test.Monica.{Project}for Monica framework projects. - Test project folder,
.csprojfile name, assembly name, andRootNamespacemust all use the sameTest.{ProductionProjectName}value. - Collection class:
{Service}Collectionwith a publicNameconstant. - Fixture class:
{Service}TestFixture. - Test class:
{TypeUnderTest}Tests. - Test method:
Method_WhenCondition_ShouldExpectation. - Field name for fixture in test classes:
_app. - Every sociable test class uses
[Collection({Service}Collection.Name)]. - Entity invariant tests may instantiate entities directly and do not need a collection.
Hard Rules
- Replace boundaries, not domain logic.
- Do not use real network, real external databases, sleeps, or browser automation in unit tests.
- Do not mock constructors just to satisfy DI. Let the service provider build the real unit under test.
- Do not use abstract
TestBaseclasses for new tests. Use fixture composition. - Do not hide assertions in setup helpers. Builders can create data; tests must state the behavior being verified.
- Keep xUnit collection parallelism disabled for Monica application tests unless Monica module state has been proven isolated for parallel host boots.
Read As Needed
references/standards.md- Stable architecture and migration rules.
references/templates.md- Copyable UserService.API-based collection, fixture, handler, query-handler, repository, module, and entity test skeletons.
references/database-isolation.md- Choosing between per-scope SQLite, shared SQLite with transaction rollback, and real provider-backed database tests.
Validation
dotnet test 'D:\Path\To\Solution\src\Tests\Test.{ProductionProjectName}\Test.{ProductionProjectName}.csproj'- Run with
--logger "console;verbosity=detailed"when checking fixture boot time. - Treat warnings from the touched test project as failures. Existing application warnings may be documented separately when they are outside the migration scope.
Source & license
This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.
- Author: Tairitsua
- Source: Tairitsua/Monica
- License: MIT
- Homepage: https://monica.dpdns.org/
Install and usage instructions live in the source repository linked above.
Reviews
No reviews yet, be the first.
Write a review
Versions
- v0.1.0 Imported from the upstream source.