qa-engineer

QA Automation Engineer skill. Use this to write or refactor unit tests. Ensures tests follow the project's xUnit, FluentAssertions, and Moq standards.

6 stars

bycwoodruff

View on GitHub Installation ↓

Best use case

qa-engineer is best used when you need a repeatable AI agent workflow instead of a one-off prompt.

QA Automation Engineer skill. Use this to write or refactor unit tests. Ensures tests follow the project's xUnit, FluentAssertions, and Moq standards.

Teams using qa-engineer should expect a more consistent output, faster repeated execution, less prompt rewriting.

When to use this skill

You want a reusable workflow that can be run more than once with consistent structure.

When not to use this skill

You only need a quick one-off answer and do not need a reusable workflow.
You cannot install or maintain the underlying files, dependencies, or repository context.

Installation

Claude Code / Cursor / Codex

$curl -o ~/.claude/skills/qa-engineer/SKILL.md --create-dirs "https://raw.githubusercontent.com/cwoodruff/morespeakers-com/main/.claude/skills/qa-engineer/SKILL.md"

Manual Installation

Download SKILL.md from GitHub
Place it in .claude/skills/qa-engineer/SKILL.md inside your project
Restart your AI agent — it will auto-discover the skill

How qa-engineer Compares

Feature / Agent	qa-engineer	Standard Approach
Platform Support	Not specified	Limited / Varies
Context Awareness	High	Baseline
Installation Complexity	Unknown	N/A

Frequently Asked Questions

What does this skill do?

QA Automation Engineer skill. Use this to write or refactor unit tests. Ensures tests follow the project's xUnit, FluentAssertions, and Moq standards.

Where can I find the source code?

You can find the source code on GitHub using the link provided at the top of the page.

SKILL.md Source

# Test Generation Skill

## Overview

Unit tests are located in `src/MoreSpeakers.Tests/`. We prioritize high coverage of Managers and critical PageModels.

## Tooling Stack

-   **Framework**: xUnit
-   **Assertions**: FluentAssertions (`result.Should().Be(...)`)
-   **Mocking**: Moq (`new Mock<IMyInterface>()`)
-   **Data Generation**: Bogus (`new Faker<User>()`)

## Test Structure

### Naming Convention
`MethodName_Scenario_ExpectedResult`

Example: `CreateUser_WhenEmailExists_ShouldReturnError`

### Arrange-Act-Assert Pattern

```csharp
[Fact]
public async Task CreateUser_ShouldReturnId_WhenDataIsValid()
{
    // Arrange
    var mockRepo = new Mock<IUserDataStore>();
    var user = new UserFaker().Generate(); // Using Bogus
    mockRepo.Setup(r => r.SaveAsync(It.IsAny<User>())).ReturnsAsync(user);

    var sut = new UserManager(mockRepo.Object);

    // Act
    var result = await sut.CreateAsync(user);

    // Assert
    result.Should().NotBeNull();
    result.Id.Should().Be(user.Id);
    mockRepo.Verify(r => r.SaveAsync(It.IsAny<User>()), Times.Once);
}
```

## Guidelines

1.  **Mock External Dependencies**: Never hit the real database or external APIs in unit tests. Use `Mock<T>`.
2.  **No Magic Strings**: Use constants or `nameof()` where possible.
3.  **Async**: Use `async Task` for all tests involving async methods.
4.  **Coverage**: Focus on business logic in `MoreSpeakers.Managers`. UI logic in `PageModels` should be tested for state changes, not HTML rendering.