Unit Testing with C# and .NET (Full Guide)

In this section, we’ll explore the world of unit testing in C# and .NET, learn what unit testing is, why it’s important, and the landscape of testing frameworks and tools available to developers.

Unit testing is the process of verifying the correctness of individual units of code, typically methods or functions, in isolation from the rest of the system. This ensures that each unit performs as expected and helps to catch potential bugs or issues early in the development process.

Unit tests are automated, self-contained, and focused on specific aspects of a unit. They should be easy to understand, maintain and execute, providing a solid foundation for any developer who wants to ensure the quality of their code.

Importance of Unit Testing in Software Development

Unit testing is a crucial practice in modern software development. Its importance can’t be overstated, since it:

• Ensures functionality: It verifies that each unit of code works as expected, avoiding bugs and other issues.
• Enhances maintainability: Well-written tests act as a safety net, allowing developers to refactor or change the code with confidence.
• Improves code quality: It encourages best practices like SOLID principles and makes developers better at writing more testable code.
• Accelerates development: Testing early and often, allows developers to detect and fix issues faster, reducing the overall time spent on debugging.
• Facilitates collaboration: Shared test suites give developers a common understanding of the code and enable smooth collaboration, and better communication.

C# and .NET Unit Test Landscape: Testing Frameworks and Tools

There are several testing frameworks and tools available for unit testing in C# and .NET, but the most popular ones are:

• xUnit: A modern, extensible testing framework that focuses on simplicity and ease of use. It is often considered the de facto choice for unit testing in .NET Core.
• NUnit: A widely used, well-established testing framework with a rich feature set and extensive plugin ecosystem. It has a long history and many legacy .NET projects use it.
• MSTest: The default testing framework provided by the Microsoft Visual Studio suite, offering tight integration with Visual Studio, and backed by Microsoft support.
• Moq: A powerful mocking library specifically designed for .NET, allowing developers to create mock objects for isolated testing of units that interact with external dependencies.

Each framework has its strengths and weaknesses, but in this article, we’ll focus on xUnit and Moq, popular choices among C# developers for unit testing.

Getting Started with xUnit: A Modern Testing Framework for C#

Now that we’re introduced to the landscape of C# unit testing, let’s dive into xUnit, learn its advantages, and set up our first unit test using the framework.

Why Choose xUnit over Other Testing Frameworks?

xUnit has emerged as a preferred choice in the .NET community for several reasons:

1. Modernity: It was designed specifically for .NET Core, bringing a contemporary approach and new features to the table.
2. Simplicity: xUnit emphasizes simplicity, making it easy to learn and use, even for developers new to unit testing.
3. Extensibility: xUnit provides many extensibility points, such as its attributes, assertions, and conventions, allowing developers to tailor it to their needs.
4. Strong community support: With broad adoption in the .NET community, xUnit has a wealth of resources, documentation, and answers to common questions.
5. Integration: It boasts integrations with popular tools like Visual Studio, VSCode, ReSharper, and .NET CLI, streamlining the testing experience.

Given these advantages, we’ll show you how to get started with xUnit in the sections below.

Installing and Setting up xUnit in Your .NET Project

To get started with xUnit, follow these easy steps:

1. Begin by creating a new .NET Core test project using your preferred method such as Visual Studio, JetBrains Rider, or the .NET CLI:

  dotnet new xunit -n MyUnitTestProject

1. Next, navigate to the project directory and then run the following command to restore the project dependencies:

  dotnet restore

1. Finally, execute your first example test with the following command:

  dotnet test

With setup complete, you’re now ready to write your own unit tests using xUnit!

Your First C# Unit Test Case with xUnit

In this section, we’ll walk through creating a simple unit test using xUnit. For our example, let’s say we have the following implementation of an Add method, inside a Calculator class:

public class Calculator
{
    public int Add(int a, int b)
    {
        return a + b;
    }
}

To write a unit test for the Add method, create a new test class in your test project called CalculatorTests. Inside this class, add a method called Add_PositiveNumbers_ReturnsExpectedResult, decorated with the [Fact] attribute, as follows:

using Xunit;
using MyProject;

public class CalculatorTests
{
    [Fact]
    public void Add_PositiveNumbers_ReturnsExpectedResult()
    {
        // Arrange
        var calculator = new Calculator();
        int a = 3;
        int b = 5;
        int expectedResult = 8;

        // Act
        int actualResult = calculator.Add(a, b);

        // Assert
        Assert.Equal(expectedResult, actualResult);
    }
}

When running the tests with dotnet test, the test suite will now execute this test and provide a pass/fail result based on whether the method behaves as expected.

xUnit Test Attributes, Conventions, and Execution Flow

xUnit uses a variety of attributes and conventions in its execution flow:

• Fact: A [Fact] attribute indicates a method as a test case. The method should neither have any return type nor any input parameters.
• Theory: A [Theory] attribute signifies a data-driven test method, allowing multiple inputs, each of which results in a separate test execution.
• InlineData: [InlineData] attribute provides inline data for [Theory] tests, simplifying test data management.
• MemberData: [MemberData] allows sharing data across test methods by specifying a member from which to pull the test data.

Additionally, xUnit has an optional convention for test execution order control, which can be customized to control test execution flow according to specific requirements.

Now that we’ve covered the basics, we’re ready to move on to more advanced unit testing techniques with xUnit and C#.

Writing Effective and Maintainable C# Unit Tests

An essential aspect of unit testing is creating tests that are easy to understand, maintain, and extend. In this section, we’ll explore the anatomy of a well-structured test, apply SOLID principles in test design, encapsulate test setup and teardown, and more.

Anatomy of a Well-Structured Test: Arrange, Act, Assert

A good unit test follows the “Arrange, Act, Assert” pattern, which makes the code simple, easy-to-understand, and maintainable. To explain this pattern, let’s break it down:

1. Arrange: Set up the test environment and instantiate the system under test or its dependencies. In practical terms, this might mean creating mock objects, setting up exception handlers, or initializing state.
2. Act: Invoke the target method using the prepared environment.
3. Assert: Check if the expected outcome equals the actual result. If not, the test fails. Try to keep your assertion count to one per test.

This pattern helps ensure that tests are logically organized and accessible, facilitating better test maintainability.

Applies SOLID Principles in Test Design

To ensure unit tests remain manageable, maintainable, and easy to understand, they should adhere to the SOLID principles, just like production code:

• Single Responsibility Principle (SRP): Each test should focus on one specific unit or behavior. Avoid mixing multiple assertions in a single test, making it easier to comprehend and troubleshoot.
• Open/Closed Principle (OCP): Ensure that tests are open for extension, meaning that adding new test cases doesn’t require modifying the existing ones.
• Liskov Substitution Principle (LSP): When using test inheritance or shared fixtures, make sure the base classes or fixtures are replaceable by their derived types without compromising test integrity.
• Interface Segregation Principle (ISP): If a test requires a specific interface, it should depend solely on that interface, rather than a larger, more complex one. This helps in narrowing down the dependencies and scope of the test.
• Dependency Inversion Principle (DIP): Depend on abstractions, rather than concrete implementations. In tests, this means using mocking frameworks like Moq to isolate tests from the actual implementation of dependencies.

Encapsulating Test Setup and Teardown

In many testing scenarios, we need to perform setup or cleanup code before or after the test execution. xUnit supports encapsulating test setup and teardown code through:

1. Constructor and IDisposable: In xUnit, the test class’s constructor is used for setup, and the IDisposable interface implementation is used for teardown. This is the most common and recommended approach.

public class MyTestFixture : IDisposable
{
    public MyTestFixture()
    {
        // Test setup code here
    }

    public void Dispose()
    {
        // Test teardown code here
    }
}

1. IAsyncLifetime: For async setup and teardown code, xUnit provides the IAsyncLifetime interface, which has InitializeAsync and DisposeAsync methods.

public class MyTestFixture : IAsyncLifetime
{
    public async Task InitializeAsync()
    {
        // Async test setup code here
    }

    public async Task DisposeAsync()
    {
        // Async test teardown code here
    }
}

C# Unit Test Best Practices: Naming, Organization and Granularity

To maintain clean and maintainable test code, it’s essential to pay attention to the organization and naming conventions. Some best practices include:

• Naming: Give your test method names descriptive titles that convey their purpose. Using a convention like MethodName_Scenario_ExpectedBehavior helps in understanding the test’s intent quickly.
• Organization: Group related tests in the same class or namespace, making it easier to locate relevant tests.
• Granularity: Aim to test a single behavior per test case. Smaller tests reduce the debugging effort if a test fails.
• Readability: Write clean and easy-to-understand tests, making it straightforward for developers to grasp the intention and expectations of a test.

Incorporating Test-Driven Development (TDD) in Your Workflow

Test-Driven Development (TDD) is a powerful development methodology that revolves around writing tests first, followed by the implementation. It follows a cyclical process of:

1. Write a failing test
2. Implement the functionality to pass the test
3. Refactor the code while keeping the test green

TDD fosters better code quality, maintainability, and overall development efficiency, as the focus is on writing simple, clear, and tested code from the start.

Advanced xUnit Techniques for Robust Test Cases

Next, let’s expand our knowledge of xUnit and explore advanced techniques to create robust test cases.

Embracing Data-Driven Tests with InlineData and MemberData

xUnit’s [Theory] attribute allows creating data-driven tests, using [InlineData] or [MemberData] to supply input values:

• InlineData: Supplies inline data values directly in the test method attribute.

[Theory]
[InlineData(1, 2, 3)]
[InlineData(-1, -2, -3)]
public void Add_TwoNumbers_ReturnsSum(int a, int b, int expectedResult)
{
    // Test implementation
}

• MemberData: Specifies a member (property or method) that returns an enumeration of test data, which should return an object array for each test case.

public static IEnumerable<object[]> TestData
{
    get
    {
        yield return new object[] { 1, 2, 3 };
        yield return new object[] { -1, -2, -3 };
    }
}

[Theory]
[MemberData(nameof(TestData))]
public void Add_TwoNumbers_ReturnsSum(int a, int b, int expectedResult)
{
    // Test implementation
}

Sharing Test Contexts Using Class and Collection Fixtures

In xUnit, test context sharing is achieved via fixtures, helping avoid code duplication and ensuring consistent setup/teardown.

• Class Fixture: Shares a single instance of a context across all tests in a class. To use a class fixture, create a class implementing the IClassFixture<T> interface, where T is the context type.

public class MyTestFixture : IClassFixture<MyContext>
{
    // Test implementation
}

• Collection Fixture: Shares a context instance across multiple test classes, useful for resource-intensive setups. Create a collection definition class implementing the ICollectionFixture<T> interface, and then apply the [CollectionDefinition] attribute.

[CollectionDefinition("MyCollection")]
public class MyCollection : ICollectionFixture<MyContext>
{
}

[Collection("MyCollection")]
public class MyTest1
{
    // Test implementation
}

[Collection("MyCollection")]
public class MyTest2
{
    // Test implementation
}

Skipping Tests and Conditional Test Execution in xUnit

Sometimes, we may want to skip tests or execute them conditionally, based on specific circumstances. xUnit provides options to facilitate this:

• Skipping tests: Use the Skip parameter on the [Fact] or [Theory] attributes to skip a test.

[Fact(Skip = "Skipping this test due to ...")]
public void MySkippedTest()
{
    // Test implementation
}

• Conditional test execution: The [ConditionalFact] and [ConditionalTheory] attributes let you conditionally execute tests, controlled by a boolean value, which can be obtained through a custom method or property.

[ConditionalFact(nameof(IsFeatureEnabled))]
public void MyConditionalTest()
{
    // Test implementation
}

private static bool IsFeatureEnabled()
{
    // Return true if feature is enabled
}

Customizing Test Output: xUnit Loggers and Reporters

In some scenarios, you may want to customize test output to generate reports or logs in various formats. xUnit supports this through a system of loggers and reporters:

• Loggers: Implement the ITestOutputHelper interface to redirect test output to custom locations or append additional information.

  public class MyTests
  {
      private readonly ITestOutputHelper _output;

      public MyTests(ITestOutputHelper output)
      {
          _output = output;
      }

      [Fact]
      public void TestWithCustomOutput()
      {
          _output.WriteLine("Custom log message");
          // Test implementation
      }
  }

• Reporters: Custom reporters can be created by implementing the IMessageSinkWithTypes interface, allowing for more fine-grained control over test output and formatting.

  public class MyCustomReporter : IMessageSinkWithTypes
  {
      public bool OnMessageWithTypes(IMessageSinkMessage message, HashSet<string> messageTypes)
      {
          // Custom test report logic here
      }
  }

Tips for Dealing with Flaky and Non-deterministic Tests

Flaky tests can cause headaches and wasted time, as their pass/fail outcome may change depending on external factors or timing. Some tips for handling non-deterministic tests include:

• Mocking: Use mocking frameworks like Moq to replace external dependencies that might cause flakiness.
• Timeouts: Use timeouts to ensure tests don’t run indefinitely due to faulty synchronization mechanisms or long delays.
• Test stability: Make your tests resilient to minor changes in the system, ensuring consistency while still checking for correctness.
• Retry: Implement retry logic for tests that intermittently fail due to transient issues.

Introduction to Mocking and Moq for C# Unit Tests

In this part, we’ll introduce the concept of mocking, its benefits, and one of the most popular mocking libraries in the .NET ecosystem, Moq.

Understanding the Purpose of Mocking and Its Benefits

Mocking is the practice of creating “fake” implementations of objects or dependencies that a system under test interacts with. This allows developers to isolate their tests from the actual implementation, enabling increased control, stability, and isolation. The benefits of mocking include:

• Test isolation: Mocks allow for complete control of test behavior and avoid side effects caused by real implementations.
• Greater flexibility: With mocks, testing becomes more flexible by enabling edge cases or exceptional scenarios that might be difficult to reproduce with actual dependencies.
• Reduced complexity: Mocks let you focus on the behavior of the system under test, instead of dealing with the complexities of real-world dependencies.
• Speed: Mocking can significantly speed up test execution by reducing resource-intensive operations or network interactions.

Moq: A Powerful and Popular Mocking Library for .NET Developers

Moq is a popular and powerful .NET mocking library that provides a simple and intuitive API for creating and managing mock objects. Key features of Moq include:

• Strong typing: Moq leverages C#’s strong typing, providing compile-time checking of mocked method calls and behavior.
• Expressive API: Moq’s API is designed to be expressive and easy to use, allowing developers to specify expectations and behaviors with minimal code.
• LINQ querying: Moq supports LINQ queries, making it simple to define complex mock behaviors and expectations.
• Integration: Moq works seamlessly with popular testing frameworks, like xUnit, making it easier to create robust and maintainable unit tests.

Integrate Moq in Your .NET Project

To get started with Moq, follow these steps:

1. Add the Moq NuGet package to your test project using your preferred method, such as Visual Studio, JetBrains Rider, or the .NET CLI:

   dotnet add package Moq

1. Add the using Moq; statement in your test classes where you plan to use mocks.
2. Use Moq’s Mock<T> class to create and configure mock objects in your tests, where T is the interface or class being mocked.

Mastering Moq: Writing Isolated Unit Tests with Mock Objects

In this section, let’s dive into Moq, learn how to create and configure mock objects, set up expectations, responses, and return values, as well as verify interactions and behaviors.

Creating and Configuring Mock Objects with Moq

To create a mock object with Moq, instantiate a Mock<T> object, where T is the interface or class being mocked. Consider the following example with an IOrderService interface:

public interface IOrderService
{
    bool PlaceOrder(Order order);
}

To create a mock object of this interface, use the following code:

var mockOrderService = new Mock<IOrderService>();

Once you’ve created a mock object, you can configure its behavior and expectations using Moq’s methods, such as Setup, Returns, Throws, and more.

Setting up Expectations, Responses, and Return Values with Moq

Moq allows you to specify expectations and responses for your methods. Let’s explore a few common scenarios:

• Returns: To specify a return value for a mocked method, use the Returns method:

  mockOrderService.Setup(x => x.PlaceOrder(It.IsAny<Order>())).Returns(true);

• Throws: To throw an exception when the mocked method is called, use the Throws method:

  mockOrderService.Setup(x => x.PlaceOrder(It.IsAny<Order>())).Throws(new InvalidOperationException());

• Callbacks: If you wish to execute specific code when a mocked method is called, use the Callback method:

  mockOrderService.Setup(x => x.PlaceOrder(It.IsAny<Order>()))
      .Callback<Order>(order => Console.WriteLine($"Order placed: {order.Id}"))
      .Returns(true);

Verifying Interactions and Behaviors: Asserting Mock Calls

Another powerful feature of Moq is the ability to verify the interactions between the system under test and the mocked dependencies. To do this, use the Verify method:

mockOrderService.Verify(x => x.PlaceOrder(It.IsAny<Order>()), Times.Once);

In this example, we’re verifying that the PlaceOrder method was called exactly once with any Order object.

Going Beyond Basics: Moq Callbacks, Sequences, and Event Raising

Moq offers more advanced options for advanced scenarios:

• Callbacks: As already mentioned, you can use Callback to execute specific code when a mock method is called. You can even capture method arguments for further validation:

  mockOrderService.Setup(x => x.PlaceOrder(It.IsAny<Order>()))
      .Callback<Order>(order => Assert.NotNull(order))
      .Returns(true);

• Sequences: If a mocked method gets called multiple times, you can set up a sequence of responses or actions using the Sequence extension:

  mockOrderService.SetupSequence(x => x.PlaceOrder(It.IsAny<Order>()))
      .Returns(true)
      .Throws(new InvalidOperationException())
      .Returns(false);

• Event Raising: Moq allows you to mock events and raise them from the mocked object:

  public interface IOrderNotifier
  {
      event EventHandler<OrderEventArgs> OrderPlaced;
  }

  var mockOrderNotifier = new Mock<IOrderNotifier>();
  // Raise the event
  mockOrderNotifier.Raise(x => x.OrderPlaced += null, new OrderEventArgs { Order = myOrder });

Moq and xUnit Integration: Use Cases and Gotchas

Integrating Moq with xUnit is straightforward since they work well together. Both libraries emphasize simplicity and usability. However, there are potential pitfalls, such as:

• Test Fixture Lifetimes: When using shared test fixtures with Moq, be aware that the fixtures’ lifetime affects the state of your mock objects. Resetting or reconfiguring them might be necessary.
• Async/Await: If your tests involve asynchronous methods, be sure to setup and verify the mock objects’ behavior accordingly.

Enhancing Unit Tests with DI and Mocking Best Practices

Now that we are more acquainted with Moq, let’s explore best practices for combining Dependency Injection (DI) and mocking in our tests.

Embracing Dependency Injection for Greater Test Flexibility

Dependency Injection (DI) is a design pattern that promotes greater test flexibility. By injecting dependencies as constructor or method parameters rather than directly instantiating them, we achieve:

• Easier mocking: Mock objects can be injected more easily, leading to better test isolation.
• Reduced coupling: Dependencies are expressed explicitly, making code easier to understand and maintain.

Try to apply DI wherever possible, particularly when working with external dependencies, allowing you to work with Moq more effectively.

When to Use Mocks, Stubs, and Fakes in Your Tests

When dealing with dependencies in your tests, it’s essential to understand when to use each type:

• Mocks: Use mocks when you need to verify interactions or behavior between the system under test and its dependencies. Useful for asserting that specific methods were called, with particular parameters, or a certain number of times.
• Stubs: Use stubs when you need to provide fixed responses or data from a dependency without asserting the behavior. They’re excellent for supplying inputs and simulating state transitions.
• Fakes: Fakes are lightweight, in-memory implementations of dependencies that replicate their essential behavior. Use them when you need more control over the dependency’s behavior or state and when mocking or stubbing isn’t sufficient.

Striking a Balance: Effective Mock Usage for Maintainable Tests

Overusing mocks can lead to brittle tests that break easily and are hard to maintain. It’s essential to strike a balance between mocking and other techniques, like stubbing or fakes. Key tips include:

• Don’t over-mock: Only mock the necessary dependencies and avoid mocking everything.
• Mock only parts of a dependency: Sometimes, you can mock parts of a dependency rather than the whole object.
• Simplicity is key: Assess whether a mock is really necessary. Using simpler alternatives such as stubs or fakes can simplify your tests.

Building Modular Tests with Factories and Builders

To further enhance the maintainability of your tests, employ factories and builders to generate mock objects, test data, or instances of your system under test:

• Factories: Create factory methods or classes that instantiate or configure common objects used throughout your test suite. This encapsulates object creation and reduces code duplication.
• Builders: Use the builder pattern to construct complex objects by allowing the incremental setting of properties or configuration. This results in more readable and flexible test code.

Measuring and Improving Test Quality with Metrics

Finally, let’s discuss how to measure test quality and make improvements using metrics such as code coverage, test quality metrics, and handling edge cases.

The Importance of Code Coverage in C# Unit Tests

Code coverage is a valuable metric that helps you understand how well your tests exercise your production code. While it doesn’t provide a complete picture of test quality, it does offer insights into potential gaps in your test suite.

Aim for a reasonable, context-specific level of code coverage. Aiming for 100% coverage isn’t always practical or efficient. Instead, determine which parts of your code require more thorough testing and ensure that critical code paths are well-tested.

Leveraging Visual Studio and .NET CLI for Code Coverage Analysis

Visual Studio and .NET CLI support analyzing code coverage, enabling you to measure the coverage of your tests effortlessly:

• Visual Studio: The Visual Studio Enterprise edition provides built-in support for code coverage analysis, featuring an easy-to-use interface and results visualization. You can also use extensions like ReSharper or dotCover for code coverage analysis in other Visual Studio editions.
• .NET CLI: You can use the dotnet test command to generate code coverage reports in various formats (Cobertura, OpenCover, etc.) by installing a coverage tool like coverlet and analyzing results with an external tool like ReportGenerator.

Beyond Code Coverage: Test Quality Metrics and Heuristics

While code coverage is useful, it’s essential to measure other aspects of test quality, including:

• Test effectiveness: Evaluate how well your tests detect actual issues in your code. High-quality tests are better at detecting defects and minimizing false negatives or positives.
• Ease of maintenance: Assess how easy your tests are to understand, modify, and extend. High-quality tests promote maintainability, reducing the cost of development over time.
• Test execution time: Monitor the time it takes to run your tests. Slow tests can hinder development and feedback cycles, reducing overall productivity.

Consider these factors when evaluating the quality of your test suite and making improvements.

Handling Edge Cases and Corner Cases: Strategies for Comprehensive Testing

Lastly, it’s vital to consider edge cases and corner cases when designing your tests. These scenarios can lead to unexpected behavior or defects and should be tested thoroughly to ensure system stability. Some strategies for handling edge cases include:

• Boundary value analysis: Test inputs or conditions at the edges of acceptable ranges. These cases often reveal problems with edge conditions or limit checks.
• Equivalence class partitioning: Divide input data into groups or classes that are expected to behave similarly, testing each group with representative values. This can help you discover issues with specific input groups.
• Error conditions: Test various ways your code can fail or encounter errors, especially in handling exceptions and error reporting. Ensure that your code gracefully handles these scenarios.
• Performance limits: Identify performance or resource constraints and test accordingly. Find out how your system behaves under high load, limited memory, or other constrained conditions.
• User behavior: Finally, consider how users interact with your application and test any unusual usage patterns or inputs. Doing so can help you uncover issues that arise from unexpected user input or actions.

In conclusion, C# and .NET offer a rich ecosystem for unit testing, with a variety of powerful frameworks and libraries like xUnit and Moq. By following the principles, patterns, and best practices discussed in this article, you can develop comprehensive and maintainable unit tests that ensure the quality, stability, and reliability of your C# applications. Keep learning, practicing, and refining your unit testing skills to become an ever-more-effective developer.

Comments

[Anthony Fung]

Wow - you weren't kidding about it being a full guide 😁

Jokes aside, an excellent article as always!

One more tip about Verify. Sometimes we want to check that something has not been called, e.g. when testing conditional branching logic. We can achieve this with:

mockOrderService.Verify(x =>
  x.PlaceOrder(It.IsAny<Order>()), Times.Never);

For anyone interested in NUnit, I'm currently writing a series on testing that contains some NUnit examples (it's currently in-progress with only a few articles at the time of this comment). I'll try to add some tips/insight that complement the information in here too.

[ByteHide]

Haha, I told you it's a full guide! 😄 Thank you for your kind words, it means a lot!

Ahh, great point! You're absolutely right - it's super helpful to verify things like that haven't been called in certain scenarios. Times.Never comes in clutch here! Your example is spot-on:

mockOrderService.Verify(x =>
  x.PlaceOrder(It.IsAny<Order>()), Times.Never);

Aah, NUnit! My tastebuds are tingling just thinking about it! 🍽️ Your series sounds awesome! I appreciate folks like you who take the time to share their knowledge with the community. Keep up and if you have any NUnit tips or insights that go well with this guide, please share, I'm all ears! 🤓 The more we can learn from each other, the more powerful we become as programmers! 💪

Thank you for your contribution, and happy testing! 🎉