coreex-test-api

Writes CoreEx API integration tests with seeded databases, outbox assertions, and HTTP mocking.

28|8|Updated Feb 21, 2022
One-click install
npx skills add https://github.com/Avanade/CoreEx --skill coreex-test-api-avanade
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: coreex-test-api
Source: https://github.com/Avanade/CoreEx/tree/main/.github/skills/coreex-test-api
Command: npx skills add https://github.com/Avanade/CoreEx --skill coreex-test-api-avanade

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve? Writing integration tests for CoreEx-based APIs requires coordinating database migration and seeding, cache clearing, outbox event expectations, ETag/concurrency semantics, and inter-domain HTTP mocks — a setup that is easy to get wrong and produces flaky or misleading tests when done ad hoc. ## Core Features & Use Cases - Structured test authoring: Guides creation of XxxReadTests/XxxMutateTests partial classes with one operation per file (Get/Query/Create/Update/Patch/Delete) over WithApiTester<{Solution}.Api.Program>. - Deterministic seeding and setup: Covers read-data.seed.yaml/mutate-data.seed.yaml conventions, ^N deterministic GUIDs, provider-specific casing (PostgreSQL snake_case vs SQL Server PascalCase), and one seed row per destructive test. - Correct assertion semantics: Encodes rules for 412 vs 409 vs 428 status codes, idempotent delete flows, provider-specific outbox event assertions (ExpectPostgresOutboxEvents/ExpectSqlServerOutboxEvents), and MockHttpClientFactory usage. - Use Case: After implementing a new Product endpoint, ask for its integration tests and receive a complete read/mutate test class pair with seed data, ETag concurrency tests, outbox event assertions, and .res.json resources. ## Quick Start Write the CoreEx API integration tests for the Product entity covering Get, Query, Create, Update, and Delete against a PostgreSQL database.

Frequently Asked Questions about coreex-test-api

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I write CoreEx API integration tests?▼

Create partial classes XxxReadTests and XxxMutateTests inheriting WithApiTester<{Solution}.Api.Program>, with one operation per sub-file. Seed data in OneTimeSetUp via MigratePostgresDataAsync or MigrateSqlServerDataAsync, then use the fluent Test.Http() chain with Run and Assert methods.

How do I seed test data for CoreEx integration tests?▼

Place read-data.seed.yaml and mutate-data.seed.yaml under Data/ in the *.Test.Common project and load them with the named-file seed overload. Use ^N for deterministic GUIDs, match database casing exactly (snake_case for PostgreSQL, PascalCase for SQL Server), and allocate one seed row per destructive test.

Should ETag concurrency failures return 412 or 409 in CoreEx tests?▼

A stale ETag returns 412 Precondition Failed, asserted with AssertPreconditionFailed(). 409 Conflict is reserved for duplicate-key or business conflicts, and a missing ETag on endpoints requiring it returns 428 Precondition Required.

How do I assert outbox events in CoreEx API tests?▼

Use the provider-specific ExpectPostgresOutboxEvents or ExpectSqlServerOutboxEvents helpers. Call AssertWithValue for value-carrying events like Create/Update, and AssertMetadata for no-value events like Delete; every publishing call needs an explicit expectation since zero events are asserted by default.

When should I not use API integration tests in CoreEx?▼

Use coreex-test-subscribe for Subscribe host tests and coreex-test-relay for Outbox Relay host tests instead. Pure unit tests for validators, aggregates, and adapters belong in *.Test.Unit projects, and implementing the controller itself is covered by the coreex-api skill.

Why does my CoreEx delete test fail when asserting 404?▼

CoreEx delete is idempotent and always returns 204 No Content, never 404. Test the four-step flow: GET returns 200, DELETE returns 204 with an outbox event, follow-up GET returns 404, and a second DELETE returns 204 with no event.