qa-engineer

cwoodruff's avatarfrom cwoodruff

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

⭐5stars🔀3forks📁View on GitHub🕐Updated Jan 7, 2026
[Testing and QA]

When & Why to Use This Skill

This Claude skill functions as a specialized QA Automation Engineer designed to streamline the unit testing lifecycle for .NET projects. It automates the generation and refactoring of high-quality test suites using industry-standard tools like xUnit, FluentAssertions, and Moq. By enforcing strict naming conventions and the Arrange-Act-Assert (AAA) pattern, it ensures your codebase remains robust, maintainable, and highly covered.

Use Cases

  • Automated Test Generation: Rapidly create comprehensive unit tests for complex business logic within Manager classes, utilizing Bogus for realistic mock data generation.
  • Legacy Code Refactoring: Update outdated test projects to adhere to modern standards, including FluentAssertions syntax and standardized naming conventions like MethodName_Scenario_ExpectedResult.
  • Dependency Mocking: Automatically configure Moq objects to isolate units of work, ensuring tests do not hit real databases or external APIs for faster and more reliable CI/CD pipelines.
  • Async Logic Validation: Ensure asynchronous methods are correctly tested using proper async/await patterns and Task-based assertions to prevent flaky tests.
nameqa-engineer
descriptionQA Automation Engineer skill. Use this to write or refactor unit tests. Ensures tests follow the project's xUnit, FluentAssertions, and Moq standards.

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

[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.