bdd-dotnet

Write BDD-style .NET unit tests using EF Core InMemory databases and fluent builders.

1|8|Updated Nov 16, 2023
One-click install
npx skills add https://github.com/zlzforever/WildGoose --skill bdd-dotnet-zlzforever
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: bdd-dotnet
Source: https://github.com/zlzforever/WildGoose/tree/main/.claude/bdd-dotnet
Command: npx skills add https://github.com/zlzforever/WildGoose --skill bdd-dotnet-zlzforever

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes scripts (resource) and references (resource) components.

What problem does it solve?

This Skill provides a robust and maintainable framework for writing Behavior-Driven Development (BDD) style unit tests for .NET domain layers, ensuring high code quality and predictable behavior.

Core Features & Use Cases

  • BDD-Style Testing: Write tests that clearly describe behavior using the Given-When-Then pattern.
  • Real Repository Implementations: Utilize EF Core InMemory databases for realistic testing without the overhead of mocks.
  • Fluent Builders: Construct complex domain objects and test data with ease using fluent APIs.
  • Fake Implementations: Create simple, controllable fakes for dependencies instead of relying on mocking frameworks.
  • Use Case: When developing a new feature, use this Skill to write comprehensive unit tests for your command and query handlers, ensuring business logic is correctly implemented and edge cases are handled before deployment.

Quick Start

Use the bdd-dotnet skill to write unit tests for the CreateProduct command handler.

Frequently Asked Questions about bdd-dotnet

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

FAQPage Schema
How do I write BDD unit tests for .NET domain layer handlers?

To write BDD unit tests for .NET domain handlers, use the Given-When-Then pattern with real repository implementations and EF Core InMemory databases. This approach creates fluent aggregate builders and fake service implementations to validate command and query handler logic predictably.

Can I use EF Core InMemory instead of mock libraries for .NET unit testing?

Yes, you can use EF Core InMemory databases instead of mock libraries for .NET unit testing. This approach employs real repository implementations with fake service implementations to test domain layer handlers realistically without the overhead of mocking frameworks.

What is the best way to structure BDD tests for command and query handlers in .NET?

The best way to structure BDD tests for .NET command and query handlers is using fluent aggregate builders with the Given-When-Then pattern. This facilitates TDD by defining clear test structures for domain logic and workflow state transitions.

How do I test time-dependent logic and workflow state transitions in a .NET domain?

To test time-dependent logic and workflow state transitions in a .NET domain, use BDD-style test structures with fake service implementations. This allows you to control time and state changes predictably while validating handler behavior through real repository implementations.

Do I need mocking frameworks to test .NET domain driven design handlers?

No, you do not need mocking frameworks to test .NET domain driven design handlers. This BDD testing approach replaces mock libraries with real repository implementations using EF Core InMemory and simple fake service implementations for dependencies.

When should I use fluent aggregate builders in .NET BDD unit tests?

You should use fluent aggregate builders in .NET BDD unit tests when you need to construct complex domain objects and test data. They provide a fluent API that makes setting up the Given state for command and query handler tests easier and more readable.