- Home
- Skills
- Kevintsengtw
- Dotnet Testing Agent Skills
- Dotnet Testing Advanced Testcontainers Nosql
dotnet-testing-advanced-testcontainers-nosql_skill
- C#
19
GitHub Stars
1
Bundled Files
2 months ago
Catalog Refreshed
4 months ago
First Indexed
Readme & install
Copy the install command, review bundled files from the catalogue, and read any extended description pulled from the listing source.
Installation
Preview and clipboard use veilstrat where the catalogue uses aiagentskills.
npx veilstrat add skill kevintsengtw/dotnet-testing-agent-skills --skill dotnet-testing-advanced-testcontainers-nosql- SKILL.md8.0 KB
Overview
This skill is a practical guide for advanced .NET integration tests using Testcontainers with MongoDB and Redis. It explains container-based fixtures, BSON serialization checks, index performance testing, and Redis data-structure coverage. The material focuses on reliable isolation, shared collection fixtures, and container lifecycle management to speed up tests and mirror production behavior.
How this skill works
The skill shows how to start real MongoDB and Redis containers via Testcontainers, create Collection Fixture patterns to share containers across xUnit tests, and run CRUD, serialization, and performance tests against those containers. It inspects BSON serialization, index behavior and uniqueness constraints in MongoDB, and verifies all five Redis data structures plus TTL and key cleanup strategies. It includes concrete cleanup and isolation patterns to avoid cross-test interference.
When to use it
- When you need true integration tests against MongoDB or Redis rather than mocks
- When validating BSON serialization and complex document models (nested objects, arrays, dictionaries)
- When testing MongoDB index performance or uniqueness constraints
- When testing Redis data structures: String, Hash, List, Set, Sorted Set and TTL behavior
- When you want fast, reliable tests using shared container fixtures to avoid repeated container startup
Best practices
- Use xUnit Collection Fixture to start containers once and share across tests to save >80% runtime
- Isolate test data with unique IDs or key prefixes instead of frequently flushing databases
- Create required MongoDB indexes in fixture initialization to measure realistic index performance
- Avoid FLUSHDB on Redis images lacking admin mode; delete keys by pattern via KeyDeleteAsync
- Use batch operations (InsertManyAsync, multi-set) for setup/teardown performance
Example use cases
- Integration test for a complex User document: BSON round-trip, nested arrays, and optimistic concurrency checks
- Performance test verifying MongoDB index response time for high-cardinality queries
- Redis cache integration tests for session store, recent views (List), and leaderboard (Sorted Set) behavior with TTL
- Shared fixture pattern that starts MongoDB and Redis once per test collection and clears test-specific keys after each test
- Uniqueness constraint test that attempts duplicate inserts against a unique index and asserts expected exceptions
FAQ
Do not rely on FLUSHDB; enumerate keys in the target database and delete them with KeyDeleteAsync to avoid admin-only operations.
When should I create indexes for tests?
Create necessary indexes during fixture initialization so tests measure index behavior consistently and avoid race conditions with test inserts.