DEV Community: Kazys

How Dyslexia Shapes My Code Style

Kazys — Sun, 02 Feb 2025 09:39:23 +0000

My Personal Experience with Reading Challenges

Code readability is subjective—some developers love compact one-liners, while others prefer structured formatting. But what if the way we format code is influenced by how our brains process language? For me, dyslexia has shaped my approach to reading, and by extension, my coding style.

I don’t have an official dyslexia diagnosis, but I’m quite certain I had it as a child and still experience some effects today, though they are less noticeable. Reading and writing were significant challenges for me growing up. My reading speed was extremely slow—even in my later school years, I could only manage about ten pages per hour, and afterward, I felt exhausted. Short texts, like mathematical problem statements, were easier to handle because I could reread them multiple times.

My struggles were especially noticeable when reading aloud—I would mix up letters, mispronounce words, and often stutter. I remember my father once telling me, even in my later school years, that I still read the same way I did when I first learned in preschool. Writing was equally difficult—I frequently skipped letters and confused similar-looking ones, like k and l or g and d.

Now, at 42 years old, I still read at a relatively slow pace. I took a couple of speed-reading lessons and learned techniques to read faster, but I’m still much slower than the average reader. Before that, I couldn’t keep up with movie subtitles and had to pause frequently when watching foreign-language films. Thankfully, I’ve improved over time, and now I can follow subtitles without struggling.

A few years ago, I joined a book club where we selected a book to read each month and then discussed it. It was a great experience—I read books I wouldn’t have chosen otherwise. However, I eventually left because keeping up with a book per month was too demanding. It took a significant amount of my free time just to catch up.

The Game-Changer: E-Book Readers

One of my biggest discoveries was using an e-book reader, particularly for EPUB files. I had owned an e-reader for a while but mostly used it to read technical PDFs. However, switching to EPUB was a game-changer—I immediately noticed how much easier it was to read when lines were shorter and the font was larger.

Here’s a screenshot of a page from Wool by Hugh Howey in my native Lithuanian language:

In contrast, here’s an example of a book that was much harder for me to read:

These images don’t show the exact scale, but I hope you get the point. For me, the most important factors are line length, line spacing, and text contrast.

How It Feels

When I struggle with dense text, it feels like standing at the edge of a great height—overwhelming and disorienting.

These reading difficulties aren’t just about books—they extend into how I read and write code. I’ve formatted my code this way for a long time, but only recently did I start to wonder if my dyslexia is the reason behind it. Here’s why I structure my code the way I do.

Code Formatting: Why I Hate One-Liners

Many years ago, I had a discussion with a former coworker about code line length. He had a large 23–24-inch screen with his code editor taking up the entire display. His panels (errors, solution explorer, etc.) were on a second monitor. He wrote extremely long lines of code—some stretching across the full width of the screen.

I remember asking him why he did that, and he confidently replied, "I want to use the entire screen efficiently!" 😐

Unfortunately, I have trouble reading long lines of code—especially when I have to scroll horizontally to see everything.

Example of Hard-to-Read One-Liner

Here’s a typical example from CodeWars:

public static int[] MoveZeroes(int[] arr)
{
    return Enumerable.Concat(arr.Select(n => n).Where(n => n > 0), arr.Select(n => n).Where(n => n == 0)).ToArray();
}

This single line technically works, and some might even be proud of it. But for me, it’s difficult to read. I immediately reformat it like this:

  public static int[] MoveZeroes(int[] arr)
  {
      return Enumerable
        .Concat(
            arr
                .Select(n => n)
                .Where(n => n > 0), 
            arr
                .Select(n => n)
                .Where(n => n == 0)
        )
        .ToArray();
  }

Yes, this version takes more lines. But I can now immediately see the logic.

And if we were still paid by lines of code, this would be even more profitable. 😉 (Although I doubt anyone is paid that way these days!)

Guidance: My Approach to Readable Code

In this section, I’ll outline the formatting principles I follow to make code more readable for myself. I'll provide examples of real production code—either as I originally encountered it or with minor adjustments to illustrate the case more clearly.

The focus here is on code formatting, not logic, design patterns, or other best practices.

General Rule: Keep It Visually Manageable

Through experience, I’ve found that code is easiest to read and understand when:

I don’t have to move my eyes left and right excessively. Instead, I prefer to read code in a vertical flow—moving only up and down.
Lines are kept within a comfortable visual span. Long horizontal lines force unnecessary scrolling and make it harder to track code structure.
Important information appears at the beginning of each line. This ensures that method names, key expressions, and logical operators are immediately visible, reducing the mental effort required to parse the code.

By following these principles, I make sure that my code remains structured, easy to scan, and effortless to navigate.

Method calls

Method calls are often written as one-liners, but when they have multiple parameters, they can become difficult to read. Sometimes, auto-formatting turns them into multi-liners, but in a way that breaks lines randomly, making the structure unclear.

Take this example:

Object o = assem.CreateInstance("Example", false,
    BindingFlags.ExactBinding,
    null, new Object[] { 2 }, null, null);

At a glance, it's hard to see how many parameters there are or distinguish their purpose.

To improve readability, I reformat it like this:

Object o = assem.CreateInstance(
    "Example", 
    false,
    BindingFlags.ExactBinding,
    null, 
    new Object[] { 2 }, 
    null, 
    null
);

Now, each parameter appears on its own line, making it much easier to:

Identify all arguments without scanning horizontally.
Quickly see which values correspond to which parameters.
Spot missing or incorrect arguments more easily.

For me, keeping parameter lists structured as a vertical list greatly improves readability and maintainability.

Method signature

Method signatures can get long, especially when they have multiple parameters with complex types. Keeping everything on a single line or chopped at random places might seem compact, but it makes scanning difficult, especially when method names vary in length or when additional parameters are added later.

For example:

protected override LanguageDataCollection CreateResult(IKey key, Expiry expiry, Source source, LocationEventKey locationEventKey, IDictionary<LanguageKey, LanguageData> dictionary)
{
    ...
}

Or, when auto-formatting splits parameters at random places, it can look like this:

protected override LanguageDataCollection CreateResult(IKey key, Expiry expiry, Source source, 
    LocationEventKey locationEventKey, IDictionary<LanguageKey, LanguageData> dictionary)
{
    ...
}

At first glance, it’s hard to quickly count parameters or see what each parameter represents.

Instead, I prefer to split parameters into separate lines, aligning them one per line:

protected override LanguageDataCollection CreateResult(
    IKey key, 
    Expiry expiry, 
    Source source, 
    LocationEventKey locationEventKey, 
    IDictionary<LanguageKey, LanguageData> dictionary
)
{
    ...
}

Following this approach makes method signatures structured and maintainable, ensuring they remain easy to work with even as they evolve.

Class declaration

Class declarations are usually short and straightforward, but when they include long inheritance chains or multiple generic parameters, they can quickly become difficult to read.

To maintain readability, I follow the same principles as in method calls:

Keep all significant elements aligned to the left.
Break long lines into shorter segments that fit within a comfortable visual span.

Example: Hard-to-Read Class Declaration

When written in a single line, a class declaration with multiple generic parameters and constraints quickly becomes cluttered:

public abstract class Popularities<TGeoPopularity, TGeoCode, TGeoEntity, TGeoName, TDetailsControl> : MatrixEntityProfileListBase<uint, TGeoPopularity, TDetailsControl>, ISomeInterface
    where TGeoPopularity : class, IGeoPopularity
    where TGeoCode : IGeoCode
    where TGeoEntity : class, IGeoEntity
    where TGeoName : class, IGeoName<TGeoCode>
    where TDetailsControl : DetailsBase<uint, TGeoPopularity>
{
    ...
}

By breaking it into multiple lines and aligning elements logically, the class definition becomes much easier to scan and understand:

public abstract class Popularities<
        TGeoPopularity, 
        TGeoCode, 
        TGeoEntity, 
        TGeoName, 
        TDetailsControl> 
    : MatrixEntityProfileListBase<
        uint, 
        TGeoPopularity, 
        TDetailsControl>, 
    ISomeInterface
    where TGeoPopularity : class, IGeoPopularity
    where TGeoCode : IGeoCode
    where TGeoEntity : class, IGeoEntity
    where TGeoName : class, IGeoName<TGeoCode>
    where TDetailsControl : DetailsBase<uint, TGeoPopularity>
{
    ...
}

Chained Method and Property Calls

Chained calls, especially in LINQ, can quickly become hard to read when squeezed into one long line:

var result = roomRateDetails.RateInfos.RateInfo.Where(c => SourceConfiguration.IncludeNonRefundables || (!c.nonRefundable & !SourceConfiguration.IncludeNonRefundables))
            .Select(rateInfo => ResultFactoryBundle.OfferFactory.CreateInstance(locationEventKey, rateInfo));

Becomes:

var result = roomRateDetails
    .RateInfos
    .RateInfo
    .Where(c => 
        SourceConfiguration.IncludeNonRefundables 
        || (!c.nonRefundable & !SourceConfiguration.IncludeNonRefundables)
    )
    .Select(rateInfo => 
        ResultFactoryBundle
            .OfferFactory
            .CreateInstance(
                locationEventKey, 
                rateInfo
            )
    );

As mentioned in the general rule—all significant information goes to the beginning of the line: method names, property names, parameters, logical operations.

Constructor with a Base Constructor Call

Constructor declarations follow the same formatting principles as methods, but constructor chaining can make them harder to read. When the base constructor call is kept in a single line, it blends with the parameter list, making it less clear.

Instead of this:

protected CommonToolsUtilityBase(DatabaseCredentialRegistry databaseCredentialRegistry, IDbServiceFactory serviceFactory,
                                    DatabaseIdentifier databaseIdentifier, HashUsage hashUsage)
    : base(databaseCredentialRegistry, serviceFactory, databaseIdentifier, hashUsage)
{
}

I prefer this:

protected CommonToolsUtilityBase(
    DatabaseCredentialRegistry databaseCredentialRegistry, 
    IDbServiceFactory serviceFactory,
    DatabaseIdentifier databaseIdentifier, 
    HashUsage hashUsage)
    : base(
        databaseCredentialRegistry, 
        serviceFactory, 
        databaseIdentifier, 
        hashUsage
    )
{
}

The constructor parameters are now clearly listed, and the base call is visually distinct, making it easier to see what is being passed where. This also helps when parameters get longer—each part remains readable without needing to scroll horizontally.

Bracket alignment

Sometimes, it’s hard to quickly see where a parameter list ends and where a new statement begins. It gets even trickier when passing method calls as parameters—figuring out whether you're dealing with a parameter of the main method, or a nested method call can take extra effort.

Example:

var enumerable = DataHandler.Instance.Query<Models.AccommodationYouTravelSourceData>(
    QueryBuilder.GetQuery(
        GetSelectQuery(),
        selector,
        this),
    selector.GetParameters().ToObject(),
    DatabaseCredential);

I prefer to align the closing bracket with the method call it belongs to, keeping indentation consistent:

var enumerable = DataHandler
    .Instance
    .Query<Models.AccommodationYouTravelSourceData>(
        QueryBuilder.GetQuery(
            GetSelectQuery(),
            selector,
            this
        ),
        selector.GetParameters().ToObject(),
        DatabaseCredential
    );

Now, each method call and its parameters are clearly structured, making it easier to follow the hierarchy without second-guessing what belongs where. It also keeps deep nesting visually manageable, avoiding the need to constantly jump between opening and closing brackets.

Line spacing

In general, I find it useful to separate statements with an empty line to improve readability. The only exceptions are simple declarations and assignments, which I usually keep together.

Take this example, where everything is packed closely together:

using (var client = new RestClient(url))
{
    client.Authenticator = new HttpBasicAuthenticator(SourceCredential.UserName, SourceCredential.Password);
    var request = new RestRequest("ordermanagement/v1/orders/" + cancelParameter.ReferenceTransactionId + "/cancel", Method.Post);
    requestResponsePair = new RequestResponsePair(DateTime.Now, request.ToString());
    var response = client.Execute(request);
    requestResponsePair.AddResponse(response.Content);
}

I prefer to add spacing between logically separate steps, making it easier to follow the sequence of operations:

using (var client = new RestClient(url))
{
    client.Authenticator = new HttpBasicAuthenticator(
        SourceCredential.UserName, 
        SourceCredential.Password
    );

    var request = new RestRequest(
        "ordermanagement/v1/orders/" 
            + cancelParameter.ReferenceTransactionId 
            + "/cancel", 
        Method.Post
    );

    requestResponsePair = new RequestResponsePair(DateTime.Now, request.ToString());

    var response = client.Execute(request);

    requestResponsePair.AddResponse(response.Content);
}

The same applies to conditionals—instead of keeping everything tight, I add spacing to visually separate decisions:

float fKilometers;
float fMiles;
bool kilometersIsdefined = float.TryParse(valueKm, out fKilometers);
bool milesIsDefined = float.TryParse(valueMi, out fMiles);
if (kilometersIsdefined)
{
    return CreateDistance(SearchRadiusUnitType.KM, fKilometers, lngCode, text);
}
if (milesIsDefined)
{
    return CreateDistance(SearchRadiusUnitType.MI, fMiles, lngCode, text);
}
return null;

Becomes:

float kilometers;
float miles;
bool kilometersIsDefined = float.TryParse(valueKm, out kilometers);
bool milesIsDefined = float.TryParse(valueMi, out miles);

if (kilometersIsdefined)
{
    return CreateDistance(
        SearchRadiusUnitType.KM,
        kilometers,
        languageCode,
        text
    );
}

if (milesIsDefined)
{
    return CreateDistance(
        SearchRadiusUnitType.MI,
        miles,
        languageCode,
        text
    );
}

return null;

Spacing isn’t just about aesthetics—it helps me process the code faster.

Mind indentation

I’ve worked a bit with Python, and one thing I really liked is how indentation is enforced by the language itself. It naturally leads to more readable code by clearly distinguishing higher-level statements from lower-level ones.

In languages where indentation isn't enforced, improper formatting can make code harder to follow:

var petraBooking = await SearchAndBookItinerary(DistributionOption.Source,
DistributionMethod.Email,
PetraSourceTestData.BillingContact,
PetraSourceTestData.Passengers,
new TrainTravelMethodOptions(false, false, false, false));

Instead, I prefer to structure parameters clearly, keeping indentation consistent and logical:

var petraBooking = await SearchAndBookItinerary(
    DistributionOption.Source,
    DistributionMethod.Email,
    PetraSourceTestData.BillingContact,
    PetraSourceTestData.Passengers,
    new TrainTravelMethodOptions(
        false, 
        false, 
        false, 
        false
    )
);

Again, all significant information is aligned to the left. No need to move my eyes side to side and then up and down—everything is visible at a glance, top to bottom.

Sometimes, the IDE automatically aligns parameters based on the first parameter’s position, leading to a stepped or cluttered look, especially when method names vary in length. This inconsistency makes scanning difficult and adds unnecessary indentation levels.

For example:

info.AddRange(roomResponse
                .Elements("ValueAdds")
                .EmptyIfNull()
                .Select(x =>
                    new EssentialInformation(Key.Empty, Expiry.Empty, CommonDataHolders.Source.EanHotels,
                        localeCode, x.StringValue("ValueAdd"), null, EssentialInfoType.Vendor)));

info.AddRangeLongerMethodName(roomResponse
                                .Elements("ValueAdds")
                                .EmptyIfNull()
                                .Select(x =>
                                    new EssentialInformation(Key.Empty, Expiry.Empty, CommonDataHolders.Source.EanHotels,
                                     localeCode, x.StringValue("ValueAdd"), null, EssentialInfoType.Vendor)));

Instead, I keep all method calls aligned to the left and indent parameters only one level for clarity:

info.AddRange(
    roomResponse
        .Elements("ValueAdds")
        .EmptyIfNull()
        .Select(x =>
            new EssentialInformation(
                Key.Empty,
                Expiry.Empty,
                CommonDataHolders.Source.EanHotels,
                localeCode,
                x.StringValue("ValueAdd"),
                null,
                EssentialInfoType.Vendor
            )
        )
);

info.AddRangeLongerMethodName(
    roomResponse
        .Elements("ValueAdds")
        .EmptyIfNull()
        .Select(x =>
            new EssentialInformation(
                Key.Empty,
                Expiry.Empty,
                CommonDataHolders.Source.EanHotels,
                localeCode,
                x.StringValue("ValueAdd"),
                null,
                EssentialInfoType.Vendor
            )
        )
);

The same applies in the following example:

 dictionary.Add(new CurrencyDataKey(currencyCode),
                  new CurrencyData(Key.Empty,
                  Expiry.Empty,
                  CommonDataHolders.Source.EanHotels,
                  currencyCode,
                  price,
                  null,
                  DateTime.Now));
return new CurrencyDataCollection(Key.Empty,
                                  Expiry.Empty,
                                  CommonDataHolders.Source.EanHotels,
                                  key,
                                  dictionary);

I reformat it to keep everything aligned logically:

dictionary.Add(
    new CurrencyDataKey(currencyCode),
    new CurrencyData(
        Key.Empty,
        Expiry.Empty,
        CommonDataHolders.Source.EanHotels,
        currencyCode,
        price,
        null,
        DateTime.Now
    )
);

return new CurrencyDataCollection(
    Key.Empty,
    Expiry.Empty,
    CommonDataHolders.Source.EanHotels,
    key,
    dictionary
);

Conditional statements

Following my general rule of keeping significant information at the beginning of the line, I prefer to place logical operators at the start of each line, rather than at the end. This makes conditions easier to track, as all operators are aligned in one column instead of being scattered at the end of lines with different lengths.

Instead of this:

if (Math.Abs(nightlyRateTotal) < 0.0001m || chargeableRateInfo.Surcharges == null ||
    chargeableRateInfo.Surcharges.Surcharge == null || chargeableRateInfo.Surcharges.Surcharge.Length < 1)

I format it like this:

if (Math.Abs(nightlyRateTotal) < 0.0001m 
    || chargeableRateInfo.Surcharges == null 
    || chargeableRateInfo.Surcharges.Surcharge == null 
    || chargeableRateInfo.Surcharges.Surcharge.Length < 1)

This way, each condition is clearly visible on its own line, and the logical flow is easy to scan without jumping to the end of different-length lines.

The same applies to ternary operations. Instead of this:

string message = (age >= 18 && country == "USA") ? "Eligible to vote in the United States elections." : "Not eligible to vote in the United States elections.";

Or this:

string message = (age >= 18 && country == "USA") ? 
    "Eligible to vote in the United States elections." : 
    "Not eligible to vote in the United States elections.";

I prefer:

string message = (age >= 18 && country == "USA") 
    ? "Eligible to vote in the United States elections." 
    : "Not eligible to vote in the United States elections.";

Here, the ternary operator (? and :) appears at the beginning of each line, making it immediately clear that this is a conditional expression.

Arithmetic Operations

Just like with logical conditions, I prefer to keep arithmetic operators aligned at the beginning of each line. This makes complex calculations easier to read, prevents operators from getting lost at the end of long lines, and helps spot errors faster.

Take this example, where operations are packed into a single line:

double finalValue = (baseValue + extraCost) * taxRate - discount / rebateFactor + serviceCharge;

When expressions become longer, it becomes harder to quickly see the order of operations and how different terms relate.

Instead, I format it like this:

double finalValue = (baseValue 
    + extraCost) 
    * taxRate 
    - discount 
    / rebateFactor 
    + serviceCharge;

Ways to Save Visual Vertical Space

Keeping lines short improves readability, but it naturally expands the code vertically. If not managed well, this can make it harder to grasp the core algorithm of a method at a glance.

One effective way to control vertical expansion is by splitting code into private methods with meaningful names. This keeps the main logic clean, making it easy to understand the flow at a high level, while detailed operations remain well-structured within smaller methods.

This way, the core algorithm stays clear, and each method remains focused, readable, and well-formatted.

Final Thoughts

Code formatting preferences vary from person to person, and agreeing on a style within a team can be difficult. Some developers love one-liners, while others (like me) find them unreadable. It took me a long time to realize that my preference for structured, short lines isn’t just a matter of style—it might be directly connected to the way I process text due to dyslexia.

But beyond personal preference, readability is about more than just individual comfort—it affects how maintainable, collaborative, and bug-free our code is. A well-structured codebase isn’t just easier for you to read today; it’s easier for your teammates (or even future you) to understand and work with tomorrow. Code that is clear, easy to scan, and logically structured reduces cognitive load, making development faster and debugging less frustrating.

At the end of the day, code isn’t just written for machines—it’s written for people. Whether you have dyslexia or not, finding a formatting style that makes code easier to read is an investment in better development practices. Readable code leads to better collaboration, fewer mistakes, and a smoother workflow.

What about you? Do you have a preferred way of formatting code? Have you noticed patterns in how you structure code that make it easier for you to read? Let’s discuss in the comments!

EasyTdd 0.5.0: Streamlining Mocking with Incremental FluentMock

Kazys — Tue, 08 Oct 2024 06:32:36 +0000

A few days ago, I released EasyTdd version 0.5.0. In this post, I'll walk through the updates and new features introduced in this version. The highlight of the release is the introduction of the incremental code generator for FluentMocks—a powerful feature implemented with the IIncrementalGenerator technology. FluentMock wraps around the popular Moq.Mock class and automatically generates setup and verify methods for every property and method of the target class, making the testing process more intuitive and readable. This implementation leverages the fluent interface design pattern, enabling method chaining that closely resembles natural language, improving code readability and maintainability. In addition to FluentMock, this update includes several key improvements and bug fixes, such as template enhancements, better file naming, and refined attribute handling, further solidifying EasyTdd’s position as a must-have tool for .NET developers focused on test-driven development. Read on to explore what’s new and how these updates can elevate your TDD experience.

Incremental FluentMock

An Overview

Let’s start by creating a FluentMock. First, install or update to EasyTdd 0.5.0. If you need help, you can follow the installation guide here. After installing, the 'Generate Incremental FluentMock' option will appear in the Quick Action menu when you right-click on an interface or abstract class declaration.:

This action, in the above case, will generate a class SomeInterfaceMock. The code looks as following:

[EasyTdd.Generators.FluentMockFor(typeof(ISomeInterface))]
public partial class SomeInterfaceMock
{
    public static SomeInterfaceMock Create()
    {
        return new SomeInterfaceMock();
    }
}

When to Use FluentMock

FluentMock is designed to simplify the process of creating, setting up, and managing mocks in your testing suite. But when is it most beneficial to use FluentMock over traditional mocking frameworks? Here are a few scenarios where FluentMock shines:

Centralized Setup Across the Solution: FluentMock enables you to define mock setups in a single place, making it easier to maintain and reuse configurations across multiple tests. This consistency ensures that any change to a mock’s behavior is automatically reflected throughout your entire test suite.
Reduced Boilerplate Code: Unlike traditional mocks, FluentMock significantly reduces repetitive setup code. This allows you to focus more on the test logic rather than the configuration details, resulting in cleaner and more maintainable tests.
Improved Readability: By using a fluent interface design pattern, FluentMock provides a more intuitive and readable syntax, resembling natural language. This makes it easier for developers to understand test scenarios at a glance, especially in complex setups.
Less Code, Fewer Mistakes: With less code required to configure and verify mocks, there’s a lower chance of introducing errors. FluentMock minimizes the verbosity of traditional mock setups, reducing the cognitive load on developers.
Foundation for Future Features: FluentMock’s streamlined structure lays the groundwork for upcoming features in EasyTdd, such as more automated code generation for other TDD scenarios. This means adopting FluentMock today will ensure a smoother transition to new capabilities as they are released.

Overall, FluentMock offers an ideal solution for developers looking to implement test-driven development (TDD) more efficiently by eliminating unnecessary boilerplate and making tests easier to manage and scale.

It is still the same old Moq.Mock

The FluentMock class is derived from the existing Moq.Mock class, meaning all the standard Moq functionality is still accessible. FluentMock streamlines the most common scenarios, but whenever you need to use the full power of Moq, you can still fall back to the regular Setup, Returns, and Verify methods as needed. Here’s an example:

// create a fluentMock with a basic setup
var mock = SomeInterfaceMock
    .Create()
    .SetupResolve(() => expectedResult0);

// use Moq.Mock regular techniquest for further setup and configuration:
mock
    .Setup(x => x.Resolve(2, It.IsAny<string>(), It.IsAny<SomeOtherResultType>()))
    .Returns(() => expectedResult2)
    .Callback(
        (int id, string value, SomeOtherResultType result) =>
        {
            // callback functionality
        }
    );

// user Moq.Mock regular Verify
mock.Verify();
mock.VerifyNoOtherCalls();

This flexibility ensures that you can leverage the power of FluentMock for simpler scenarios while retaining full control over more complex test configurations using traditional Moq methods.

FluentMock vs. Traditional Moq: Setup Comparison

FluentMock Setup: Compact and Readable

The FluentMock code is automatically generated in the background and is immediately ready to use:

public class UsageTest
{
    [Test]
    public void Test()
    {
        var expectedResult0 = new SomeResultType();
        var expectedResult1 = new SomeResultType();
        var expectedResult2 = new SomeResultType();

        var mock = SomeInterfaceMock
            .Create()
            .SetupResolve(
                () => expectedResult0
            )
            .SetupResolve(
                () => expectedResult1,
                isId: x => x == 1
            )
            .SetupResolve(
                () => expectedResult2,
                isId: x => x == 2
            );

        mock
            .Object
            .Resolve(
                1,
                "Jon",
                new SomeOtherResultType()
            )
            .Should()
            .Be(expectedResult1);

        mock
            .Object
            .Resolve(
                2,
                "Tom",
                new SomeOtherResultType()
            )
            .Should()
            .Be(expectedResult2);

        mock
            .Object
            .Resolve(
                8,
                "Jennifer",
                new SomeOtherResultType()
            )
            .Should()
            .Be(expectedResult0);
    }
}

In the code example above the mock is set up to return expectedResult1 when provided id is 1, return expectedResult2 when provided id is 2, and expectedResult0 in all other cases.

Traditional Moq Setup: Verbose and Detailed

Let's take a look at how the setup would look with a pure Moq.Mock:

var expectedResult0 = new SomeResultType();
var expectedResult1 = new SomeResultType();
var expectedResult2 = new SomeResultType();

var mock = new Mock<ISomeInterface>(MockBehavior.Strict);

mock
    .Setup(
        x =>
            x.Resolve(
                It.IsAny<int>(),
                It.IsAny<string>(),
                It.IsAny<SomeOtherResultType>()
            )
    )
    .Returns(() => expectedResult0);


mock
    .Setup(
        x =>
            x.Resolve(
                1,
                It.IsAny<string>(),
                It.IsAny<SomeOtherResultType>()
            )
    )
    .Returns(() => expectedResult1);

mock
    .Setup(
        x =>
            x.Resolve(
                2,
                It.IsAny<string>(),
                It.IsAny<SomeOtherResultType>()
            )
    )
    .Returns(() => expectedResult2);

I prefer short lines so to look fare I will compare setup in one-liners:

// FluentMock Setup Example:
var mock = SomeInterfaceMock
    .Create()
    // Sets up Resolve to return expectedResult0 for all inputs by default
    .SetupResolve(() => expectedResult0)
    // Sets up Resolve to return expectedResult1 when the 'id' parameter is 1
    .SetupResolve(() => expectedResult1, isId: x => x == 1)
    // Sets up Resolve to return expectedResult2 when the 'id' parameter is 2
    .SetupResolve(() => expectedResult2, isId: x => x == 2);

//vs

// Traditional Moq Setup Example:
var mock = new Mock<ISomeInterface>(MockBehavior.Strict);

mock
    // Sets up Resolve to return expectedResult0 for any combination of parameters
    .Setup(x => x.Resolve(It.IsAny<int>(), It.IsAny<string>(), It.IsAny<SomeOtherResultType>()))
    .Returns(() => expectedResult0);

mock
    // Sets up Resolve to return expectedResult1 when 'id' is 1 and the other parameters are any values
    .Setup(x => x.Resolve(1, It.IsAny<string>(), It.IsAny<SomeOtherResultType>()))
    .Returns(() => expectedResult1);

mock
    // Sets up Resolve to return expectedResult2 when 'id' is 2 and the other parameters are any values
    .Setup(x => x.Resolve(2, It.IsAny<string>(), It.IsAny<SomeOtherResultType>()))
    .Returns(() => expectedResult2);

FluentMock pros: Easy to read, compact, and utilizes method chaining, which closely resembles natural language.

Verification Example: FluentMock vs. Traditional Moq

The same applies to verification. The example below checks that the mock was called with an id value of 1, a name value of Jon, and a SomeOtherResult with an id value of 100:

mock
    .VerifyResolve(
        x => x == 1,
        x => x == "Jon",
        x => x.Id == 100
    );

//vs

mock
    .Verify(
        x => x.Resolve(
            1,
            "Jon",
            It.Is<SomeOtherResultType>(
                x => x.Id == 100
            )
        )
    );

Reusable FluentMock Setups

The FluentMock approach also offers a convenient place to have setups for a specific interface in one place. For example if I have an interface INameLookup:

public interface INameLookup
{
    public string Lookup(int id);
}

In many testing scenarios, it is enough that the service returns something relevant to the provided input. I might want to create a lightweight fake implementation with the help of FluentMock:

[EasyTdd.Generators.FluentMockFor(typeof(INameLookup))]
public partial class NameLookupMock
{
    public static NameLookupMock Create()
    {
        var mock = new NameLookupMock();

        return mock.SetupLookup((int id) => $"name_of_{id}");
    }
}

Whenever INameLookup is needed in a test, the NameLookupMock.Create() can be used, which produces the expected results.

One more example could be with a repository:

public interface IOrderRepository
{
    Task<Order> Get(int id);
}

And the mock:

[EasyTdd.Generators.FluentMockFor(typeof(IOrderRepository))]
public partial class OrderRepositoryMock
{
    public static OrderRepositoryMock Create()
    {
        var mock = new OrderRepositoryMock();

        return mock.SetupGet((int id) => OrderBuilder.Random().WithId(id));
    }
}

Pretty cheap fake, when specific values are not required but calling code needs a repository which returns something on each call.

Different ways to set up

I will explore every possible use case in detail in a separate blog series, but for now, I'll quickly highlight the added value. Below I will provide a list of setups with descriptions of them:

 SomeInterfaceMock
    .Create()
    // setup to return expectedResult0 on every Resolve call
    .SetupResolve(() => expectedResult0)
    // setup to return expectedResult1 when id parameter value is 1
    .SetupResolve(() => expectedResult1, isId: x => x == 1)
    // setup to return expectedResult2 when Id value of someOtherResult parameter is 100
    .SetupResolve(() => expectedResult2, isSomeOtherResult: x => x.Id == 100)
    // setup to return dynamic value depending on the input
    .SetupResolve(
        (int id, string name, SomeOtherResultType someOtherResultType) =>
            new SomeResultType
            {
                Id = id, 
                Name = $"name of {id}"
            }
    )
    // setup to throw an exception when input name is "Ted"    
    .SetupResolve(() => throw new Exception("Something went wrong"), isName: x => x == "Ted");

Similar goes for verification:

// verifies if Resolve was called with specific parameters
mock
    .VerifyResolve(
        x => x == 1,
        x => x == "Jon",
        x => x.Id == 100
    );

// verifies if Resolve was called with value "John"
mock
    .VerifyResolve(
        isValue: x => x == "John"
    );

// verifies if Resolve was called with value "John" exactly twice
mock
    .VerifyResolve(
        isValue: x => x == "John",
        times: () => Times.Exactly(2)
    );

// verifies if Resolve was called at least once
mock
    .VerifyResolve();

Configuration

The default placement, naming, and location of the generated FluentMock may not suit everyone's preferences and requirements. Fortunately, all of these aspects can be easily customized to better align with your needs and tastes. Now, I will provide the settings one by one. Settings for the incremental FluentMock, as well as for all other tools, are located in the settings.json file under the IncrementalTestDoubleForAbstract section. Here are the descriptions:

ClassSuffix: The default value is Mock. This value determines the suffix added to the target class's corresponding fluent mock class name. In the previous example, for ISomeInterface, the fluentMock class name was SomeInterfaceMock.
NameInMenu: The default value is Generate Incremental FluentMock. This setting allows you to modify the name displayed in the Quick Actions menu. By default, it is Generate Incremental FluentMock, but you can rename it to whatever you prefer.
AssemblySpecificTargetProjectSuffix: The default value is TestDoubles. This setting instructs EasyTdd to place the generated builder in a project corresponding to the project of the target class. It searches for a project with the same name as the target class’s project, but with the predefined suffix appended. For example, if ISomeInterface is in the project EasyTdd.CodeSource.CodeProject1, the corresponding project for the fluent mock would be EasyTdd.CodeSource.CodeProject1.TestDoubles. This can be customized to suit individual preferences and requirements, such as using a different suffix for the test doubles project. Within the test doubles project, EasyTdd maintains the original folder hierarchy.
TargetProjectNameForAssembliesWithoutSpecificTargetProject: The default value is null. This setting specifies a project name where a test double will be placed when the project of a target class doesn't have a corresponding test double project. For example, if you want to place all test doubles from all projects into a single test doubles project called EasyTdd.CodeSource.TestDoubles, you would set this setting to EasyTdd.CodeSource.TestDoubles. In this case, you can leave AssemblySpecificTargetProjectSuffix with its default value. EasyTdd will first try to find a project with the predefined suffix and, if it doesn’t find one, it will fall back to the value in TargetProjectNameForAssembliesWithoutSpecificTargetProject. If EasyTdd doesn't locate the project specified in TargetProjectNameForAssembliesWithoutSpecificTargetProject, it will place the test double class next to the target class.
Folder: The default value is Mocks. This setting allows you to organize test doubles, such as builders and mocks, into corresponding folders. For example, if you choose to have a single project for all test doubles, set TargetProjectNameForAssembliesWithoutSpecificTargetProject to EasyTdd.CodeSource.TestDoubles and Folder to Mocks. In this case, the fluent mock for EasyTdd.CodeSource.CodeProject1\Services\ISomeInterface.cs will be placed in EasyTdd.CodeSource.TestDoubles\Mocks\CodeProject1\Services\SomeInterfaceMock.cs.
FileTemplates: This section contains settings for the specific files that will be generated.
- NameTemplate: The default value is {{className}}.cs for the EasyTdd-generated part, and {{className}}.g.cs for the EasyTdd.Generators-generated part. Here, className is a template variable that refers to the name of the FluentMock class.
- ContentTemplateFile: The default value for the EasyTdd-generated part is DefaultTemplates\incremental.fluentmock.tpl. The default value for the EasyTdd.Generators part is DefaultTemplates\moq.incremental.fluentmock.g.tpl.
- Recreate: The Recreate setting determines how files are generated. If set to true, the files are generated by the incremental generator (EasyTdd.Generators). If set to false, they are generated by the EasyTdd Visual Studio extension. The files generated by EasyTdd are intended for modifications, such as fluent mock setups. In contrast, the files generated by EasyTdd.Generators will be regenerated whenever changes are made to the target class.
ToolingNamespaces: By default, this contains a list of namespaces to support the tooling used in the default fluent mock template. EasyTdd automatically adds target class-related namespaces to the generated class, but it is not aware of the namespaces required by the tooling in the template. This setting allows you to specify those additional namespaces manually. By default, the Moq and System namespaces are added to support functionality provided in the templates.

Feel free to update the templates to match your taste and needs. Remember to copy and paste them outside of the DefaultTemplates folder, as the templates in this folder are overridden with each new release. It is even possible to use some other mocking library in the background like FakeItEasy or some other.

Other updates and fixes in the 0.5.0

Nullable Support

With the latest release templates now are aware if nullable is enabled for the project. Templates are updated accordingly and now generated code reflects that:

Unified generated file naming

Now, the file names are consistent whether a builder or a FluentMock is generated by the incremental generator or created as a regular class. Now in both cases the file which is a subject for regeneration is suffixed with .g. In above case it will be SomeInterfaceMock.g.cs and SomeInterfaceMock.cs.

Added links to a menu to all generated files

When non incremental build or fluentMock was created two files were generated and Quick Actions menu showed a link to only one. Now both files are shown:

Added Build(int count) to the builder template to build multiple objects

Now, each builder has a Build(int count, Func<int, TBuilder, TBuilder>? adjust = null) method, and multiple objects can be built by adjusting each with the adjust method:

var values = WithGenericBuilder<int>
    .Default()
    .Build(
        10, 
        (index, builder) => builder
            .WithSomeInt(index)
            .WithSomeString($"name of {index}")
    )
    .ToList();

Updated test case generation to not require test attributes on the test

Now test attribute is not required for a test to generate test cases. It is enough for a method to be public and EasyTdd adds all required attributes:

And the result:

[TestCaseSource(typeof(SampleTestCases))]
public void SampleTest(int a, int b, int c)
{
    Assert.That(c, Is.EqualTo(a + b));
}

Awareness of methods and properties of the base class

Now, the test generator, builder, and FluentMock generators recognize the properties and methods of the base class and generate the corresponding members accordingly.

Summary

With the release of EasyTdd version 0.5.0, FluentMock is poised to make unit testing even more powerful and accessible for .NET developers. Its intuitive syntax, reduced boilerplate, and the ability to handle complex setups and verifications with ease make it a great addition to any test-driven development toolkit. This release also introduces several other important enhancements, including improved support for nullable reference types, a unified naming convention, and refined templates, ensuring a smoother experience for both new and existing users.

If you’re already using EasyTdd, give FluentMock a try and let me know your experience in the comments below or reach out to me on LinkedIn. For new users, now is a great time to explore EasyTdd! Try it out with FluentMock, Incremental Builder, and other test-driven development-enhancing features that make creating test doubles and managing test cases a breeze.

Stay tuned for future posts where I’ll dive deeper into specific scenarios and share tips on getting the most out of EasyTdd. Make sure to subscribe or follow for updates so you don’t miss out on the next article. Until then, happy testing!

Builder: Your Buddy in Test-Driven Development (TDD)

Kazys — Mon, 19 Aug 2024 13:25:57 +0000

Builder pattern

Today, I will talk about the builder pattern in test-driven development. If you are already working with tests, you have probably noticed how time-consuming it can be to create all the input data. Often, the same set of data, or data with slight differences, is used across many tests in a system's test suite. The Builder helps here. It serves two purposes:

The builder allows developers to construct test data objects step by step, using a fluent interface that enhances readability and reduces verbosity.
The builder class is an excellent place to define and collect all common and edge case objects. For example, for a Passenger, it could be Man, Woman, Boy, Girl, Infant, etc. For an Itinerary, it could be One-way, Round trip, Direct, Indirect, etc.

For a sake of an example I will take Invoice class, a very simplified version could be something like this:

public class Invoice
{
    public Invoice(
        string invoiceNo, 
        string customer, 
        string countryCode, 
        DateTime invoiceDate, 
        IReadOnlyList<InvoiceLine> lines)
    {
        InvoiceNo = invoiceNo;
        InvoiceDate = invoiceDate;
        Customer = customer;
        CountryCode = countryCode;
        Lines = lines;
    }

    public string InvoiceNo { get; }
    public string Customer { get; }
    public string CountryCode { get; }
    public DateTime InvoiceDate { get; }
    public decimal TotalAmount => Lines.Sum(x => x.TotalPrice);
    public IReadOnlyList<InvoiceLine> Lines { get; }
}

public class InvoiceLine
{
    public InvoiceLine(
        string itemCode, 
        decimal unitCount, 
        decimal unitPrice, 
        decimal vat)
    {
        ItemCode = itemCode;
        UnitCount = unitCount;
        UnitPrice = unitPrice;
        Vat= vat;
    }

    public string ItemCode { get; }
    public decimal UnitCount { get; }
    public decimal UnitPrice { get; }
    public decimal Vat { get; }
    public decimal TotalPrice => UnitCount * UnitPrice * (1 + Vat / 100);
}

To create an Invoice object I have to provide many values to the constructors of Invoice and InvoiceLine. In many cases, only a portion of properties are relevant to specific tests. Here builders come in to help.

Builder for InvoiceLine could look something like this:

public partial class InvoiceLineBuilder
{
    private string _itemCode;
    private decimal _unitCount;
    private decimal _unitPrice;
    private decimal _vat;

    public static implicit operator InvoiceLine(InvoiceLineBuilder builder) => builder.Build();

    public static InvoiceLineBuilder Default()
    {
        return new InvoiceLineBuilder(
            "001",
            1,
            100,
            21
        );
    }

    public InvoiceLineBuilder(
        string itemCode,
        decimal unitCount,
        decimal unitPrice,
        decimal vat)
    {
        _itemCode = itemCode;
        _unitCount = unitCount;
        _unitPrice = unitPrice;
        _vat = vat;
    }

    public InvoiceLine Build()
    {
        return new InvoiceLine(
            _itemCode,
            _unitCount,
            _unitPrice,
            _vat
        );
    }

    public InvoiceLineBuilder WithItemCode(string value)
    {
        _itemCode = value;
        return this;
    }

    public InvoiceLineBuilder WithUnitCount(decimal value)
    {
        _unitCount = value;
        return this;
    }

    public InvoiceLineBuilder WithUnitPrice(decimal value)
    {
        _unitPrice = value;
        return this;
    }

    public InvoiceLineBuilder WithVat(decimal vat)
    {
        _vat = value;
        return this;
    }
}

Builder for Invoice could look something like this:

public partial class InvoiceBuilder
{
    private string _invoiceNo;
    private string _customer;
    private string _countryCode;
    private DateTime _invoiceDate;
    private IReadOnlyList<InvoiceLine> _lines;

    public static implicit operator Invoice(InvoiceBuilder builder) 
        => builder.Build();

    public static InvoiceBuilder Default()
    {
        return new InvoiceBuilder(
            "S001",
            "AB VeryImportantCustomer",
            "SV",
            DateTime.Parse("2024-01-01"),
            new []
            {
                InvoiceLineBuilder
                    .Default()
                    .Build()
            }
        );
    }

    public InvoiceBuilder(
        string invoiceNo,
        string customer,
        string countryCode,
        DateTime invoiceDate,
        IReadOnlyList<InvoiceLine> lines)
    {
        _invoiceNo = invoiceNo;
        _customer = customer;
        _countryCode = countryCode;
        _invoiceDate = invoiceDate;
        _lines = lines;
    }

    public Invoice Build()
    {
        return new Invoice(
            _invoiceNo,
            _invoiceDate,
            _lines
        );
    }

    public InvoiceBuilder WithInvoiceNo(string value)
    {
        _invoiceNo = value;
        return this;
    }

    public InvoiceBuilder WithCustomer(string value)
    {
        _customer = value;
        return this;
    }

    public InvoiceBuilder WithCountryCode(string value)
    {
        _countryCode = value;
        return this;
    }

    public InvoiceBuilder WithInvoiceDate(DateTime value)
    {
        _invoiceDate = value;
        return this;
    }

    public InvoiceBuilder WithLines(IReadOnlyList<InvoiceLine> value)
    {
        _lines = value;
        return this;
    }

    public InvoiceBuilder WithLines(params InvoiceLine[] value)
    {
        _lines = value;
        return this;
    }
}

In case when a test needs an Invoice object just for its total price property then Invoice can be created like this:

var invoice = InvoiceBuilder
    .Default()
    .WithLines(
        InvoiceLineBuilder
            .Default
            .WithUnitPrice(158)
    );

As the total price is calculated by summing invoice lines, and the default unit count for the invoice line is 1 then it is enough to set the unit price for the invoice line. If similar functionality is needed in multiple tests we could go further and add the following method to the InvoiceBuilder:

public static InvoiceBuilder DefaultWithTotalPrice(decimal totalPrice)
{
    return new InvoiceBuilder(
        "S001",
        DateTime.Parse("2023-01-01"),
        new[]
        {
            InvoiceLineBuilder
                .Default()
                .WithUnitPrice(totalPrice)
                .Build()
        }
    );
}

Collection of predefined setups

As mentioned above, the builder class is a great place to collect all common and edge cases for the class. Here, I will provide a few of those possible cases.:

An invoice with items having regular VAT
An invoice with items having reduced VAT
An invoice with items having mixed VAT
An invoice to an EU country
An invoice to a USA country
An invoice to China

From my point of view, it is a great place to gather knowledge about the different cases our system handles. It serves as a useful knowledge base for new developers to understand what the system needs to manage. If I'm new to a field, I might not even think of possible edge cases. Here is a code example from some of the cases mentioned above:

public static InvoiceBuilder ForEUCountry()
{
    return Default()
        .WithCountryCode("SV");
}

public static InvoiceBuilder ForUSA()
{
    return Default()
        .WithCountryCode("USA");
}

public static InvoiceBuilder ForChina()
{
    return Default()
        .WithCountryCode("CN");
}

public InvoiceBuilder WithRegularVat()
{
    return this
        .WithLines(
            InvoiceLineBuilder
                .Default
                .WithItemCode("S001")
                .WithVat(21),
            InvoiceLineBuilder
                .Default
                .WithItemCode("S002")
                .WithVat(21)
        );
}

public InvoiceBuilder WithReducedVat()
{
    return this
        .WithLines(
            InvoiceLineBuilder
                .Default
                .WithItemCode("S001")
                .WithVat(9),
            InvoiceLineBuilder
                .Default
                .WithItemCode("S002")
                .WithVat(9)
        );
}

public InvoiceBuilder WithMixedVat()
{
    return this
        .WithLines(
            InvoiceLineBuilder
                .Default
                .WithItemCode("S001")
                .WithVat(21),
            InvoiceLineBuilder
                .Default
                .WithItemCode("S002")
                .WithVat(9)
        );
}

Now we can create a mix of the above. For example, if a test case needs an invoice for an EU customer with invoice lines that have mixed VAT, I can do the following:

[Test]
public void SomeTest()
{
    //arrange
    var invoice = InvoiceBuilder
        .ForEU()
        .WithMixedVat();

    //act
    ...
    //assert
    ...
}

This is just a simple example, but I hope you understand the concept.

A builder is useful when we have a large, complex object, but only a few fields are relevant to the test.

Another useful case is when I want to test multiple scenarios based on specific values. All properties except one remain the same, and I change only one. This makes it easier to highlight the difference, which causes the service or object to behave differently.

Ways to create the builder class

Code with your own hands

First, you can create a builder class on your own. This doesn't require any initial investment of time or money, and you have a lot of freedom in how you build it. Copying, pasting, and replacing can be useful, but it still takes quite a bit of time, especially for larger classes.

Create Your Own Code Generator

When I started with code generation, I began by setting up a single test for it. This test didn't actually test anything; it just accepted a type, retrieved all properties using reflection, created a builder class from a hardcoded template, and wrote it to the test runner output window. All I had to do was create a class file and copy/paste the content from the test runner's output window.

BuilderGenerator

All about BuilderGenerator can be found here. It explains the .NET Incremental Source Generator. This means the builder code is regenerated live when the target class changes. So, there's no hassle or manual work compared to the methods above. Just create a builder class, add the BuilderFor attribute with the target class type, and all With methods are generated automatically and ready to use.

[BuilderFor(typeof(InvoiceLine))]
public partial class InvoiceLineBuilder
{
    public static InvoiceLineBuilder Default()
    {
        return new InvoiceLineBuilder()
            .WithItemCode("S001")
            .WithUnitCount(1);
    }
}

I haven't worked with it much, but it seems to have a wide user base with 82.7K downloads at the time of writing. I noticed a couple of issues that make me choose other options:

The solution fails to build if the builder class is in a different project than the target class. It can be in another project, but the namespace must remain the same. Otherwise, you will see the following errors:

It does not support constructor parameters and fails with errors if the target class does not have a parameterless constructor.:

Let's explore what other options we have.

Bogus.Faker generator

This is a very popular library with over 82.2M total downloads (and 186.1K for the current version) at the time of writing. As the author of the library states, it is a fake data generator capable of producing numerous objects based on predefined rules. It isn't exactly what the builder pattern is in TDD, but it can be adapted. There are several ways to use Bogus.Faker, but I will focus on how to mimic the builder pattern here.

The simplest way to create an object with Bogus.Faker is:


[Test]
public void BogusTest()
{
    var faker = new Faker<InvoiceLine2>();

    var invoiceLine = faker.Generate();

    Assert.IsNotNull(invoiceLine);
}

It creates an instance of InvoiceLine2 with default values, which means nulls and zeros. To set some values, I will use the following setup:

[Test]
public void BogusTest()
{
    var faker = new Faker<InvoiceLine2>()
        .RuleFor(x => x.ItemCode, f => f.Random.AlphaNumeric(5))
        .RuleFor(x => x.UnitPrice, f => f.Random.Decimal(10, 1000))
        .RuleFor(x => x.UnitCount, f => f.Random.Number(1, 5))
        .RuleFor(x => x.Vat, f => f.PickRandom(21, 9, 0));

    var invoiceLine = faker.Generate();

    Assert.IsNotNull(invoiceLine);

    ToJson(invoiceLine);
}

The code above creates an invoice line object with random values. An example might look like this:

{
  "ItemCode": "gwg7y",
  "UnitCount": 3.0,
  "UnitPrice": 597.035612417891230,
  "Vat": 0.0,
  "TotalPrice": 1791.106837253673690
}

It is useful, but each test requires its own setup. Instead, we can create a builder class:

public class InvoiceLineBuilder: Faker<InvoiceLine2>
{
    public static InvoiceLineBuilder Default()
    {
        var faker = new InvoiceLineBuilder();

        faker
            .RuleFor(x => x.ItemCode, f => f.Random.AlphaNumeric(5))
            .RuleFor(x => x.UnitPrice, f => f.Random.Decimal(10, 1000))
            .RuleFor(x => x.UnitCount, f => f.Random.Number(1, 5))
            .RuleFor(x => x.Vat, f => f.PickRandom(21, 9, 0));

        return faker;
    }
}

Usage would look something like this:

[Test]
public void BogusTest()
{
    var faker = TestDoubles.Bogus.InvoiceLineBuilder
        .Default()
        .RuleFor(x => x.ItemCode, f => "S001")
        .RuleFor(x => x.UnitPrice, f => 100);

    var invoiceLine = faker.Generate();

    Assert.IsNotNull(invoiceLine);

    ToJson(invoiceLine);
}

And the output:

{
  "ItemCode": "S001",
  "UnitCount": 2.0,
  "UnitPrice": 100.0,
  "Vat": 9.0,
  "TotalPrice": 218.00
}

From my perspective, it is a bit more verbose than the regular Builder Pattern. Additionally, I am not a fan of using random values. It is not a big problem, but issues arise when a class's properties are initialized using a constructor and it doesn't have setters. Then it doesn't work as a builder, and each setup becomes static.

var faker = new InvoiceLineBuilder();

faker
    .CustomInstantiator(f => 
        new InvoiceLine(
            f.Random.AlphaNumeric(5),
            f.Random.Decimal(10, 1000),
            f.Random.Number(1, 5),
            f.PickRandom(21, 9, 0)
        )
    );

NBuilder

This is also a very popular library with over 13.2 million total downloads (and 7.2 million for the current version). Though it has not been actively developed recently, the last version was released in 2019. Essentially, it is very similar to Bogus.Faker. It should even be possible to reuse Bogus for providing random values by implementing a specific IPropertyNamer.

Let's try using it without setting any properties:

[Test]
public void NBuilderTest()
{
    var invoiceLine = Builder<InvoiceLine2>
        .CreateNew()
        .Build();

    Assert.IsNotNull(invoiceLine);

    ToJson(invoiceLine);
}

It produces the following output::

{
  "ItemCode": "ItemCode1",
  "UnitCount": 1.0,
  "UnitPrice": 1.0,
  "Vat": 1.0,
  "TotalPrice": 1.01
}

The aim of this post is to show how to create a reusable builder class. Let's get started:

public class InvoiceLineBuilder
{
    public static ISingleObjectBuilder<InvoiceLine2> Default()
    {
        return Builder<InvoiceLine2>
            .CreateNew()
            .With(x => x.ItemCode, "S001")
            .With(x => x.UnitCount, 1)
            .With(x => x.UnitPrice, 100)
            .With(x => x.Vat, 21);
    }
}

And here is the usage:

[Test]
public void NBuilderTest()
{
    var invoiceLine = TestDoubles.NBuilder.InvoiceLineBuilder
        .Default()
        .With(x => x.ItemCode, "S002")
        .With(x => x.Vat, 9)
        .Build();

    Assert.IsNotNull(invoiceLine);

    ToJson(invoiceLine);
}

And the output:

{
  "ItemCode": "S002",
  "UnitCount": 1.0,
  "UnitPrice": 100.0,
  "Vat": 9.0,
  "TotalPrice": 109.00
}

Similar to Bogus.Faker, you cannot override values if a class property is set using a constructor and does not have a setter. If you try to use the With method for such a property, it will fail with the following exception:

 System.ArgumentException : Property set method not found.

EasyTdd.Generators.Builder

EasyTdd.Generators.Builder is a Nuget package and works in tandem with the EasyTdd - the Visual Studio Extention. This package leverages a .NET incremental source generator to create builders from templates used by the EasyTdd extension. The builder generator handles property setters, constructor parameters, and a combination of both. It also supports generic parameters.

This is my preferred way to create a builder. Here are the benefits compared to the other options:

The builder class is generated just with a few clicks.
Incremental source generator is used for the builder class generation. This causes builder class automatic updates on every change in the source class.
Templating support. You can easily adapt the template for my needs.
Seamless support for classes that can be initialized using both constructor parameters, setter properties or mix of both.
Generic class support.

When the EasyTdd is installed in the Visual Studio, open the quick action menu on the target class and select "Generate Incremental Builder":

This action creates a partial builder class with the BuilderFor attribute set:

[EasyTdd.Generators.BuilderFor(typeof(InvoiceLine))]
public partial class InvoiceLineBuilder
{
    public static InvoiceLineBuilder Default()
    {
        return new InvoiceLineBuilder(
            () => default, // Set default itemCode value
            () => default, // Set default unitCount value
            () => default, // Set default unitPrice value
            () => default  // Set default vat value
        );
    }
}

The builder code itself in generated in the background, and this partial class is intended for common/edge case setups. Feel free to set default values instead of default.

More about setting it up and how it works can be found here.

The good part is that if I need random values, I can use Bogus here:

public static InvoiceLineBuilder Random()
{
    var f = new Faker();

    return new InvoiceLineBuilder(
        () => f.Random.AlphaNumeric(5),
        () => f.Random.Decimal(10, 1000),
        () => f.Random.Number(1, 5),
        () => f.PickRandom(21, 9, 0)
    );
}

Usage:

[Test]
public void EasyTddBuilder()
{
    var invoiceLine = TestDoubles.Builders.InvoiceLineBuilder
        .Random()
        .WithUnitPrice(100)
        .WithUnitCount(1)
        .Build();

    Assert.IsNotNull(invoiceLine);

    ToJson(invoiceLine);
}

And the output:

{
  "ItemCode": "ana0i",
  "UnitCount": 1.0,
  "UnitPrice": 100.0,
  "Vat": 9.0,
  "TotalPrice": 109.00
}

Pure EasyTdd

The EasyTdd also offers full builder code generation without the dependency to EasyTdd.Generators Nuget package. This is useful if you do not want or you are not allowed to depend on third party libraries. The extention generates the code and all is in your project, no dependencies, no strings attached. Feel free to modify it all is yours. This approach offers all the benefits as with EasyTdd.Generators case, except automatic regeneration on target class changes. In this case the builder needs to be regenerated manually (also with a few clicks). Two files are generated to void loosing the setups on regeneration. One file contains the builder class declaration, with all necessary methods, the other is intended just only for setups and additional methods, which are not intended for regeneration. The class can be generated in similar way as above, by opening the quick action menu and clicking "Generate Builder":

When the builder is already generated the tool offers to open the builder class or to regenerate:

Summary

In this blog post, I introduced the builder pattern and its use in test-driven development. I also showed several ways to implement it, starting from manual implementation, using third-party libraries like Bogus.Faker and NBuilder, incremental code generators like BuilderGenerator and EasyTdd.Generators.Builder, and finally, having all code generated by the EasyTdd Visual Studio extension. Each method has its strengths and weaknesses and works well in simple cases. However, when dealing with immutable classes, EasyTdd stands out by handling property changes equally, whether a property value is initialized by a setter or through a constructor parameter. EasyTdd supports templates and allows you to customize the output to match your preferences. EasyTdd also surpasses other methods of implementing a builder due to its speed of implementation. It provides tools in Visual Studio to generate files automatically with just a few clicks, saving time and effort.

EasyTdd 0.4.0 Release: Introducing the Incremental Builder

Kazys — Thu, 23 May 2024 06:29:04 +0000

I'm excited to announce the release of EasyTdd 0.4.0! The major highlight of this release is the introduction of the Incremental Builder, implemented using the IIncrementalGenerator technology.

The Builder Pattern is a creational design pattern that provides a way to construct complex objects step by step. It allows for the creation of different representations of an object using the same construction process. This pattern is particularly useful in test-driven development (TDD) because it simplifies the creation of test data and makes tests more readable and maintainable by providing a clear and fluent interface for constructing test objects.

One of the biggest benefits of using a builder in TDD is the ability to predefine specific valid setups, such as "Default" or "Typical," along with other specific cases. In a test, you can use these predefined setups or modify just one or two fields as needed. This approach ensures that your tests are consistent and easy to understand, focusing on the behavior being tested rather than the details of object creation.

IIncrementalGenerator is a powerful feature in C# supported in .NET 6.0 and later. It enhances source generation by processing and updating only the parts of the code that have changed, with the code being generated in the background.

How to use it?

Let's say we have a sample class:

namespace EasyTdd.CodeSource.CodeProject1.ForIncrementalBuilder
{
    public class SampleWithGeneric<T>
        where T: class, IEnumerable
    {
        public SampleWithGeneric(T someProperty, string someString)
        {
            SomeProperty = someProperty;
            SomeString = someString;
        }

        public T SomeProperty { get; }
        public string SomeString { get; set; }
        public int SomeInt { get; set; }
        public DateTime SomeDateTime { get; set; }
    }
}

In Visual Studio with EasyTdd installed, place the cursor on the class for which you want to create a builder. Open the Quick Action menu (either by clicking the light bulb with the mouse or pressing Ctrl+. on the keyboard) and select "Generate Incremental Builder."

This action will produce a partial builder class with the BuilderFor attribute set:

namespace EasyTdd.CodeSource.CodeProject1.TestDoubles.Builders.ForIncrementalBuilder
{
    [EasyTdd.Generators.BuilderFor(typeof(SampleWithGeneric<>))]
    public partial class SampleWithGenericBuilder<T>
    {
        public static SampleWithGenericBuilder<T> Default()
        {
            return new SampleWithGenericBuilder<T>(
                () => default, // Set default someProperty value
                () => default, // Set default someString value
                () => default, // Set default someInt value
                () => default  // Set default someDateTime value
            );
        }
    }
}

This file is where the default and other known setups of the class can be defined. The templates only define the "default" setup, so feel free to change the default values and define as many setups as you need. This file is protected from regeneration and will not be affected by changes in the target class.

namespace EasyTdd.CodeSource.CodeProject1.TestDoubles.Builders.ForIncrementalBuilder
{
    [EasyTdd.Generators.BuilderFor(typeof(SampleWithGeneric<>))]
    public partial class SampleWithGenericBuilder<T>
    {
        public static SampleWithGenericBuilder<T> Default()
        {
            return new SampleWithGenericBuilder<T>(
                () => default,
                () => "",
                () => 0, 
                () => DateTime.Now
            );
        }
        public static SampleWithGenericBuilder<T> SomeSpecificCase(T value)
        {
            return new SampleWithGenericBuilder<T>(
                () => value,
                () => "some specific string",
                () => 782,
                () => DateTime.Parse("2024-05-20")
            );
        }
    }
}

The rest of the class is generated by Roslyn, the .NET compiler platform. You can see the outcome by pressing F12 (or checking Edit > Go To Definition if your shortcut scheme has changed) on the SampleWithGenericBuilder<T>:

The code in SampleWithGenericBuilder.g.cs looks as following:

namespace EasyTdd.CodeSource.CodeProject1.TestDoubles.Builders.ForIncrementalBuilder
{
    public partial class SampleWithGenericBuilder<T>
        where T : class, System.Collections.IEnumerable
    {
        private Func<T> _someProperty;
        private Func<string> _someString;
        private Func<int> _someInt;
        private Func<System.DateTime> _someDateTime;

        public static implicit operator EasyTdd.CodeSource.CodeProject1.ForIncrementalBuilder.SampleWithGeneric<T>(SampleWithGenericBuilder<T> builder) => builder.Build();

        public SampleWithGenericBuilder(
            Func<T> someProperty,
            Func<string> someString,
            Func<int> someInt,
            Func<System.DateTime> someDateTime)
        {
            _someProperty = someProperty;
            _someString = someString;
            _someInt = someInt;
            _someDateTime = someDateTime;
        }

        public SampleWithGenericBuilder(
            T someProperty,
            string someString,
            int someInt,
            System.DateTime someDateTime)
        {
            _someProperty = () => someProperty;
            _someString = () => someString;
            _someInt = () => someInt;
            _someDateTime = () => someDateTime;
        }

        public EasyTdd.CodeSource.CodeProject1.ForIncrementalBuilder.SampleWithGeneric<T> Build()
        {
            return new EasyTdd.CodeSource.CodeProject1.ForIncrementalBuilder.SampleWithGeneric<T>(
                _someProperty(),
                _someString())
            {
                SomeInt = _someInt(),
                SomeDateTime = _someDateTime()
            };
        }

        public SampleWithGenericBuilder<T> WithSomeProperty(Func<T> value)
        {
            _someProperty = value;
            return this;
        }

        public SampleWithGenericBuilder<T> WithSomeProperty(T value)
        {
            return WithSomeProperty(() => value);
        }

        public SampleWithGenericBuilder<T> WithSomeString(Func<string> value)
        {
            _someString = value;
            return this;
        }

        public SampleWithGenericBuilder<T> WithSomeString(string value)
        {
            return WithSomeString(() => value);
        }

        public SampleWithGenericBuilder<T> WithSomeInt(Func<int> value)
        {
            _someInt = value;
            return this;
        }

        public SampleWithGenericBuilder<T> WithSomeInt(int value)
        {
            return WithSomeInt(() => value);
        }

        public SampleWithGenericBuilder<T> WithSomeDateTime(Func<System.DateTime> value)
        {
            _someDateTime = value;
            return this;
        }

        public SampleWithGenericBuilder<T> WithSomeDateTime(System.DateTime value)
        {
            return WithSomeDateTime(() => value);
        }
    }
}

I want to note that generic constraints are added automatically. The generator takes into account which properties are set using the constructor and which have only setter properties.

Usage of the builder

The beauty and power of the builder pattern lie in its flexibility and simplicity. When using a builder, I do not need to specify all the properties—only the ones relevant to a test—even when the constructor of the type is complex and requires many fields to be set. This makes the builder especially useful in scenarios where the type has a heavy constructor with numerous parameters. By using a builder, I can create objects with only the necessary properties, making my tests more focused and easier to read. This approach not only reduces boilerplate code but also enhances the maintainability and clarity of the test suite.

public void Demo()
{
    var orderSample = SampleWithGenericBuilder<List<Order>>
        .SomeSpecificCase(new List<Order>())
        .WithSomeString("Order list case");

    var defaultSample = SampleWithGenericBuilder<List<Item>>
        .Default();

    var listOfSamples = new List<SampleWithGenericBuilder<List<Item>>>
    {
        SampleWithGenericBuilder<List<Item>>
            .Default()
            .WithSomeInt(1),
        SampleWithGenericBuilder<List<Item>>
            .Default()
            .WithSomeInt(2),
        SampleWithGenericBuilder<List<Item>>
            .Default()
            .WithSomeInt(3),
        SampleWithGenericBuilder<List<Item>>
            .Default()
            .WithSomeInt(4),
    };
}

How it works?

The solution consists of three parts: EasyTdd, the Visual Studio extension itself; the settings and template files; and the EasyTdd.Generators NuGet package. When you click "Generate Incremental Builder," EasyTdd considers the settings to determine where the builder needs to be placed, creates the file, and renders the content using a template specified in the settings. If the EasyTdd.Generators NuGet package is not already installed in the target project, EasyTdd installs it. EasyTdd.Generators contains the logic to create the BuilderFor attribute class and generate the builder class for a type defined in the BuilderFor parameter. The rest is accomplished by Roslyn, the .NET compiler platform.

Configuration

The default placement, naming, and location of the generated builder may not suit everyone's preferences and requirements. Fortunately, all of these aspects can be easily customized to better align with your needs and tastes. Now, I will provide the settings one by one. Settings for the incremental builder, as well as for all other tools, are located in the settings.json file under the IncrementalTestDoubleForConcrete section. Here are the descriptions:

ClassSuffix: The default value is Builder. This value determines the suffix added to the target class's corresponding builder class name. In the previous example, for SampleWithGeneric, the builder class name was SampleWithGenericBuilder.
NameInMenu: The default value is Generate Incremental Builder. This setting allows you to modify the name displayed in the Quick Actions menu. By default, it is Generate Incremental Builder, but you can rename it to whatever you prefer.
AssemblySpecificTargetProjectSuffix: The default value is TestDoubles. This setting instructs EasyTdd to place the generated builder in a project corresponding to the project of the target class. It searches for a project with the same name plus the predefined suffix. For example, if SampleWithGeneric is in the project EasyTdd.CodeSource.CodeProject1, the corresponding project for the builder would be EasyTdd.CodeSource.CodeProject1.TestDoubles. This can be customized to suit individual preferences and requirements, such as using a different suffix for the test doubles project. Within the test doubles project, EasyTdd maintains the original folder hierarchy.
TargetProjectNameForAssembliesWithoutSpecificTargetProject: The default value is null. This setting specifies a project name where a test double will be placed when the project of a target class doesn't have a corresponding test double project. For example, if you want to place all test doubles from all projects into a single test doubles project called EasyTdd.CodeSource.TestDoubles, you would set this setting to EasyTdd.CodeSource.TestDoubles. In this case, you can leave AssemblySpecificTargetProjectSuffix with its default value, as EasyTdd will first try to find a project with the predefined suffix and then fall back to the value in TargetProjectNameForAssembliesWithoutSpecificTargetProject if it doesn't find one. If EasyTdd doesn't locate the project specified in TargetProjectNameForAssembliesWithoutSpecificTargetProject, it will place the test double class next to the target class.
Folder: The default value is Builders. This setting allows you to organize test doubles, such as builders and mocks, into corresponding folders. For example, if you choose to have a single project for all test doubles and set TargetProjectNameForAssembliesWithoutSpecificTargetProject to EasyTdd.CodeSource.TestDoubles and Folder to "Builders," then the builder for EasyTdd.CodeSource.CodeProject1\Models\SampleWithGeneric.cs will be placed in EasyTdd.CodeSource.TestDoubles\Builders\CodeProject1\Models\SampleWithGeneric.cs.
FileTemplates: This section contains settings for the specific files that will be generated.
- NameTemplate: The default value is {{className}}.cs for the EasyTdd-generated part, and {{className}}.g.cs for the EasyTdd.Generators-generated part. Here, className refers to the name of the builder class.
- ContentTemplateFile: The default value for the EasyTdd-generated part is DefaultTemplates\incremental.builder.tpl. The default value for the EasyTdd.Generators part is DefaultTemplates\incremental.builder.g.tpl.
- Recreate: Files marked with true are generated by the incremental generator, EasyTdd.Generators, while files marked with false are generated by the EasyTdd Visual Studio extension. The files generated by EasyTdd are intended for modifications, such as builder setups. In contrast, the files generated by EasyTdd.Generators will be regenerated whenever changes are made to the target class.
ToolingNamespaces: By default, this contains a list of namespaces to support the tooling used in the default test template. EasyTdd adds target class-related namespaces to the generated class, but it is not aware of the tooling used in the template itself. This is where you can define those namespaces. By default, the System namespace is added to support Func in the template.

Summary

In this blog post, I introduced the new version of EasyTdd. This new version includes a powerful tool—the incremental builder—which is automatically updated whenever the target class changes. The code generation is highly configurable and easily changeable, allowing you to tailor it to your specific needs. Additionally, I discussed how the builder pattern and IIncrementalGenerator enhance the test-driven development experience by streamlining the creation of test data and improving build performance. This tool takes types with generic parameters into account and works seamlessly with classes where values are set using constructors, setter properties, or a mix of both. With these new features, EasyTdd offers a more efficient and scalable approach to managing test doubles and supporting large projects.

Kickstart Test-Driven Development with EasyTdd

Kazys — Wed, 03 Apr 2024 05:53:19 +0000

This time, I'll keep the text brief. Instead, I've created a video that covers much of what I've already written in my previous blog post. Specifically, you'll find the first steps of test-driven development, examples with parameterized tests, and how to create test cases for them.

You'll become familiar with how tedious and demotivating it can be to do this manually, and you'll see how quickly tasks can be completed with EasyTdd. I expect this video will provide a better grasp of what EasyTdd offers and where its strengths lie.

Additional material:

For installing EasyTdd, refer to: https://www.youtube.com/watch?v=FC0qqgMYTAE
For detailed instructions on configuring test generation, visit: https://easytdd.dev/easytdd-quick-start-a-short-and-simple-introduction
For configuring test case generation, check out: https://easytdd.dev/creating-test-cases-for-parameterized-tests

Happy and easy development!

The importance of having a red test first in test driven development

Kazys — Mon, 26 Feb 2024 06:44:14 +0000

My name is Kazys Račkauskas, and I'm writing about test-driven development. In this blog post, I want to discuss the importance of starting with a red test. The red-green-refactor cycle is a well-known mantra in test-driven development. To recap:

Red - write a piece of test code for the functionality you want to implement. It must be red since the functionality is not there yet. One of the main ideas is that the tests should guide the development process.
Green - write a piece of code for the test to pass.
Refactor - eliminate code duplicates, enhance readability, improve aesthetics, possibly extract some methods or create new classes, and optimize. Don't forget to refactor both the production code and the test code.

Why red?

I very rarely do post-code testing (perhaps there is a better-known expression for writing tests after writing production code). I do that when I encounter a piece of code not covered with tests that I need to put my hands on. And I'm happy when the test is green, making me feel the code works as expected. Test-driven development is not only about writing tests to make sure the production code works as expected, but it is rather (as the name suggests) a process of development. A couple of things pop into my head when I think about Red in TDD. First is demand; I produce the production code when it is needed (red test), I need to meet the demand. Second - YAGNI (You Aren’t Gonna Need It), I do not produce the code which is not needed, I do not code too much, because it might not be needed.

I'm just a human after all

I'm only human, and I make mistakes. I make mistakes in production code and test code alike. The idea for this blog post came last week when I encountered situations where the test was not red, and it was very tempting to leave it as is because it was GREEN. This was especially true when there were already several tests, leading me to think that I might have already covered the case. It may sound like an oxymoron, but a GREEN test in the first step of TDD is a RED flag.. In the following sections, I will provide cases that I encountered last week where I made a mistake in the test, causing it to be green, but it was incorrect.

it vs if

I'm a backend developer and use TDD a lot. However, sometimes I have to work with front-end and do JavaScript development. I do my best to practice TDD while doing JavaScript development as well.

For JavaScript testing, I use karma as a test runner and jasmine as a test framework. In jasmine, the describe function sets a test case, and the it function defines an individual test. I want to share how I mistyped it as if multiple times, leading to a false impression of all passing tests.

it('Seat map is selected when person of the seat map is selected', 
    function () {
        let seatMaps = result.Seating.SeatMaps;
        expect(seatMaps[0].Selected).toBeTrue();
        seatMaps[2].Passengers[1].select();
        expect(seatMaps[2].Selected).toBeTrue();
    }
);

and

if('Seat map is selected when person of the seat map is selected', 
    function () {
        let seatMaps = result.Seating.SeatMaps;
        expect(seatMaps[0].Selected).toBeTrue();    
        seatMaps[2].Passengers[1].select();
        expect(seatMaps[2].Selected).toBeTrue();
    }
);

In all modern development environments and text editors for developers, if is usually highlighted in a different color. I'm not colorblind, but it is still easy for me to miss it. Additionally, I find that my finger muscle memory is used to typing a two-letter word starting with i as if. It just happens automatically. As a result, there are no errors, and it is a valid sentence. All tests appear green when I run them. It is easy to notice when it is the first test because it will show that 0 tests have been run. However, it is more difficult when there are more tests. In this particular situation, my initial thought was, "aha, I already covered this functionality.". Fortunately, my experience with treating green tests as a red flag saved me.

Missing the attribute

This example is in C#. While it's not taken from production code, it captures the essence:

[DataRow(1, 2, 3)]
[DataRow(2, 3, 5)]
public void SomeFakeTest(int a, int b, int c)
{
    Assert.AreEqual(c, a + b);
}

In the MsTest test framework, the DataRow attribute alone is insufficient to mark a method as a test. The TestMethod or DataTestMethod attribute is required for the method to be recognized as a test. I have found myself forgetting this attribute a few times, which resulted in tests not being run and creating a false impression of all tests passing.

Missing assertion

The following example, which I adapted from my previous blog post, demonstrates the situation. I recall the instances when I write a test - I think of a test case, a test name, arrange it, then act, and then - get distracted. When I return to see where I left off, I usually run the tests to see the red ones and continue from there. But in this particular case, all are green. This case is tricky; it's easy to forget that I left the test unfinished, and it's green because it doesn't have an assertion.ertions.

[TestCaseSource(typeof(UnexpectedPaymentMessageIsSentWhenInvoiceIsOverpaidOrUnknownCases))]
public async Task UnexpectedPaymentMessageIsSentWhenInvoiceIsOverpaidOrUnknown(
    Invoice invoice,
    string message)
{
    _invoiceRepositoryResult = invoice;

    await CallCallback();
}

Misread

Recently, I needed to modify the functionality of a DTO converter to return passengers in order by sequenceNumber, rather than in a somewhat random manner. I'm using FluentAssertions, which allows passing configuration in the BeEquivalentTo method. I simply typed config.With, and Visual Studio's IntelliSense suggested a list of options. I chose the first one that started with With and ended with Ordering.

seatMapDto
    .Passengers
    .Select(x => x.FirstName)
    .Should()
    .BeEquivalentTo(
        new[]
        {
            "GUDMARIN",
            "GUDMARIANA",
            "TOM"
        },
        config => config.WithoutStrictOrdering(),
        "should be ordered by sequenceNumber"
    );

I ran the test, and it was green. Since I expected the test to be red, I began by making sure that the input data was unordered in the arrange part to create a nonsequential order for the test to be red. Only later did I realize that I had chosen the WithoutStrictOrdering configuration instead of WithStrictOrdering.

Wrapping it up

Being human and making mistakes is not easy :). In this blog post, I wanted to showcase how sometimes silly mistakes can give the impression that tests are green, and emphasize the importance of starting with a red test first.

Have you encountered similar situations where a mistake in a test led you to believe that production was working as expected? Please share your experiences in the comments.

If you enjoyed this post, please click "like" and "follow". Feel free to explore my other blog posts, where I write about test-driven development and my pet project EasyTdd, a Visual Studio extension that makes test-driven development simpler.

Creating Test Cases for Parameterized Tests

Kazys — Wed, 14 Feb 2024 07:30:59 +0000

Hello, my name is Kazys Račkauskas, and welcome to my third blog post. I'm writing about test-driven development and introducing my pet project, EasyTdd—a tool designed to streamline the TDD process by generating test-related code. In my first blog post, Easy way to start TDD, I covered the entire thought process behind TDD, including my approach, the steps I take, and provided examples. In my second blog post, EasyTdd Quick Start: A Short and Simple Introduction, I dI delved deeper into EasyTdd's test-from-template generation feature, highlighting its configurability to suit various needs and preferences. In this blog post, I will discuss the test case source method and class generation for parameterized tests.

The problem

There are many instances when having a parameterized test is quite convenient. For specific input, a specific output is expected, eliminating the need to write a test method for each case—all within a single test method. Each testing framework has an attribute to provide values for parameterized tests. For MsTest, it would be DataRow; for NUnit, TestCase; and for xUnit, MemberData.

[TestCase("3", 3)]
[TestCase("3.5", 3.5)]
[TestCase("2+2", 4)]
[TestCase("2.5-2.8", -0.3)]
[TestCase("10+20-5.5+8-3+2.8", 32.3)]
public void ReturnsExpectedCalculatedExpression(
    string expression, 
    double expectedResult)
{
    _expression = expression;

    var result = CallCalculate();

    result
        .Should()
        .BeApproximately(expectedResult, 0.001);
}

It works well and is quite useful. However, the issue is that the attribute only allows constant expressions, typeof expressions, and array creation expressions. You will not be successful if a complex type is needed as a parameter.

Fortunately, there are other attributes such as DynamicData, TestCaseSource, and ClassData for MsTest, NUnit, and xUnit, respectively.

[TestCaseSource(nameof(GetCallbackBadRequestWhenRequestIsNotValidCases))]
public async Task CallbackBadRequestWhenRequestIsNotValid(
    PaymentCallbackRequest request)
{
    _request = request;

    var result = await CallCallback();

    result
        .Should()
        .BeOfType<BadRequestResult>();
}

private static IEnumerable<TestCaseData> GetCallbackBadRequestWhenRequestIsNotValidCases()
{
    yield return new TestCaseData(
            new PaymentCallbackRequest { AmountPaid = 200, InvoiceNo = null }
        )
        .SetName("Invoice no is null");

    yield return new TestCaseData(
            new PaymentCallbackRequest { AmountPaid = -1, InvoiceNo = "xx1" }
        )
        .SetName("AmountPaid is negative");
}

In the above example, test cases are provided in the test class method, but it is possible to do the same in a separate class. This approach is convenient and effective. However, what I found annoying is the need to remember the structure and type repeatedly or resort to copying and pasting from elsewhere for each test. EasyTDD features—'Generate Test Cases' and 'Generate Test Cases in External File'—come to the rescue here. With just one click, you can have a test-specific method for test cases or even a separate class.

You might say, "not a big deal." Yes, but there are still some benefits

It saves precious seconds and speeds up the process.
It keeps me concentrated on the problem.
It maintains the same structure across the tests.

Generate Test Cases

Usage

When you have a parameterized test method open, open the Quick Action menu on the test method, and click 'Generate Test Cases'. This action adds the attribute depending on the test framework used in the test project and generates a test method-specific method with placeholders for a couple of test cases. It also adds the test cases attribute to use the newly generated method as a test cases source.

For above CallbackBadRequestWhenRequestIsNotValid test it would generate something like this:

[Test]
[TestCaseSource(nameof(GetCallbackBadRequestWhenRequestIsNotValidCases))]
public async Task CallbackBadRequestWhenRequestIsNotValid(
    PaymentCallbackRequest request)
{
    _request = request;

    var result = await CallCallback();

    result
        .Should()
        .BeOfType<BadRequestResult>();
}

private static IEnumerable<TestCaseData> GetCallbackBadRequestWhenRequestIsNotValidCases()
{
    yield return new TestCaseData(
            default //Set value for request
        )
        .SetName("[Test display name goes here]");

    yield return new TestCaseData(
            default //Set value for request
        )
        .SetName("[Test display name goes here]");
}

All you need to do is add the necessary test data, run the tests (remember, they should fail initially), implement the code, verify that the tests pass, and finally, refactor as needed.

Configuration

As noted in the EasyTdd quick start blog post, all configurations are located in the solution's .easyTdd folder. You can find templates there, as well as a settings.json file which gathers all configurations. The "Generate Test Cases" feature has a "TestCases" section in the settings.json file. Here are the descriptions:

NameInMenu - the default value is Test Cases. This minor setting enables you to modify the name displayed in the Quick Actions menu. By default, it will be "Generate Test Cases", but you can rename it to whatever you prefer. For instance, when MsTests are used, the DynamicData attribute is employed. Perhaps you want to name this action "Generate Dynamic Data". Alternatively, in the case of xUnit, you might opt for "Generate Member Data".
DefaultTestFramework - the default value is NUnit. EasyTdd attempts to identify the testing framework used in the target test project. If it fails to recognize the framework, it will use templates for the test framework specified here.
OutputSettings - this section contains configurations for NUnit, MsTest, and xUnit testing frameworks. Each configuration has the same structure, so I will provide an overview of the structure without focusing on a specific testing framework.
- AttributeTemplateFile - the default value for NUnit is "DefaultTemplates\nunit.test-cases.attribute.tpl". Here is a path to the template for a test cases source attribute. You might want to change the test cases source method name template.
- SourceMethodTemplateFile - the default value for NUnit is "DefaultTemplates\nunit.test-cases.source-method.tpl". Here is the path to the template for a test cases source method. You might want to change the test cases source method name, formatting, or structure.
- TestAttributeNames - the default value for NUnit is [ "Test", "TestCase" ]. This indicates how attributed methods for test cases source method can be generated. I added this setting as otherwise I found it hard to distinguish regular methods from test methods.

As mentioned above, there are two templates associated with this feature: templates associated with the AttributeTemplateFile and SourceMethodTemplateFile settings values. In most cases, defaults should be okay, but if you want to experiment a bit, don't forget to copy/paste the template from DefaultTemplates to the .easyTdd root folder, make changes, save, and update settings.json accordingly. Do not make any changes to templates in DefaultTemplates - those might be overridden with changes after the next release.

Generate Test Cases in External Class

Usage

Open the Quick Action menu on the parameterized test method, and click "Generate Test Cases In External File". This is very similar to "Generate Test Cases", but in this case, the test case source method is generated in a separate class. It is very useful when test cases take up a lot of visual space, as it helps to keep the test code itself cleaner. The "Generate Test Cases In External File" action accomplishes a couple of things:

It adds a test framework-specific attribute with values set for the class for test cases.
It generates a class with a method and a couple of placeholders for data.
It adds the newly added class's using directive to the test class.

For the above CallbackBadRequestWhenRequestIsNotValid test, it would generate something like this:

[Test]
[TestCaseSource(typeof(CallbackBadRequestWhenRequestIsNotValidCases))]
public async Task CallbackBadRequestWhenRequestIsNotValid(
    PaymentCallbackRequest request)
{
    _request = request;

    var result = await CallCallback();

    result
        .Should()
        .BeOfType<BadRequestResult>();
}

And the test case source class:

using System.Collections;

namespace EasyTdd.Blog.No1.MoreComplexExample.PaymentService.Tests.Controllers.TestCases.PaymentControllerTests;

public class CallbackBadRequestWhenRequestIsNotValidCases : IEnumerable
{
    public IEnumerator GetEnumerator()
    {
        yield return new TestCaseData(
                default //Set value for request
            )
            .SetName("[Test display name goes here]");

        yield return new TestCaseData(
                default //Set value for request
            )
            .SetName("[Test display name goes here]");
    }
}

Configuration

The "Generate Test Cases In External Class" feature has a section named TestExternalCases in the settings.json file. Here are the descriptions:

NameInMenu - the default value is "Test Cases In External File". This minor setting enables you to modify the name displayed in the Quick Actions menu. By default, it will be "Generate Test Cases In External File", but as mentioned in the above section, you can rename it to whatever you prefer.
SourceFilePathTemplate - the default value is TestCases{{testClassName}}. In this particular case, it means that a "TestCases" folder is created in the test's folder, followed by a folder named after the test class name. This is the path for all test case source classes for the test class. In Solution Explorer, it will look something like this:

**SourceClassNameTemplate** - the default value is `{{testName}}Cases`. This is the name template for the test cases source class. If the test name is `ResultShouldBeSumOfArguments`, then the test cases source class name will be `ResultShouldBeSumOfArgumentsCases`.

OutputSettings - this section contains configurations for NUnit, MsTest, and xUnit testing frameworks. Each configuration has the same structure, so I will provide an overview of the structure without focusing on a specific testing framework.
- AttributeTemplateFile - the default value for NUnit is "DefaultTemplates\nunit.test-cases-external.attribute.tpl". Here is the path to the template for a test cases source attribute.
- SourceClassTemplateFile - the default value for NUnit is "DefaultTemplates\nunit.test-cases-external.source-class.tpl". Here is the path to the template for a test cases source class. You might want to change the test cases source class name, formatting, or structure.
- TestAttributeNames - the default value for NUnit is [ "Test", "TestCase" ]. This indicates how attributed methods for test cases source method can be generated.
- ToolingNamespaces - the default value for NUnit is [ "NUnit.Framework", "System.Collections" ]. Here additional namespaces could be defined which will be added to the model's usingNamespaces collection. For example, the default class template uses IEnumerable and TestCaseData class, so the above namespaces are required for the code to compile.

Summary

In this blog post, I have covered how to generate test cases methods and test cases classes for parameterized tests. I have also provided information on how it could be configured. I think in most cases, default values should work fine, but feel free to change for your taste and needs. It is not ChatGTP nor other AI, but still, I believe EasyTdd can save a couple of precious seconds or maybe even minutes per test, help to keep the same structure across the tests, and avoid the distraction of needing to type boilerplate code. As a reminder - EasyTdd can be downloaded from Visual Studio Extension Manager or directly from EasyTdd - Visual Studio Marketplace.

EasyTdd Quick Start: A Short and Simple Introduction

Kazys — Tue, 30 Jan 2024 06:49:24 +0000

This is my second blog post. The first one wasn't successful, as it was broad but shallow. I aimed to establish a foundation and build upon it, but I felt like I fell into a state similar to analysis paralysis. I needed to release something to free up my mind and continue somehow. I admit it was too long; a few of my colleagues told me they clicked "like" but didn't read it because it was too lengthy. In this post, I will focus solely on the easyTdd tool, how it can help by generating test templates, and how it can be configured to suit your needs. I won't cover all the features in this blog post, just test generation, but with more depth. In my next blog post, I will cover method and class generation for test cases of parameterized tests, in a similar manner to how I discuss test generation today. As a reminder, EasyTdd is a Visual Studio extension that aids in test-driven development by generating test templates and other useful code blocks. It can be installed directly from the Visual Studio Extension Manager or downloaded from the Visual Studio Marketplace.

ReSharper

EasyTdd features are implemented using the Visual Studio Quick Action menu. ReSharper may override this menu and hide it. To enable it, navigate to ReSharper's options and uncheck "Hide Visual Studio Quick Action icons in the left editor margin":

Configuration

When a solution is opened, EasyTdd checks for the settings. If nothing is found, it generates an .easyTdd folder in the solution folder. Inside, it adds a default settings.json file and DefaultTemplates folder with collection of template files.

Each feature has its own section in the settings.json file, accompanied by one or more template files. Templates are written in the Scriban scripting language. All configurations are solution-specific and can be customized to fit particular project requirements. Feel free to make any necessary changes to the settings.json file. If changes are needed in a template, copy and paste it, then make the changes there. Don't forget to update the corresponding template name in the settings.json file. Default templates are updated with every release, so any changes made directly to them will be lost.

Test generation in details

Once EasyTdd is installed on Visual Studio and ReSharper is configured as mentioned above, invoking the Quick Actions menu on a class declaration will display the "Generate Test" action, as shown below:

Clicking on it, EasyTdd will generate a CalculatorTests class in the ClassLibrary.Tests project, similar to the following:

namespace ClassLibrary.Tests
{
    public class CalculatorTests
    {
        private string _expression;

        [SetUp]
        public void Setup()
        {
            _expression = string.Empty;
        }

        [TestCase(null)]
        public void CalculateThrowsArgumentExceptionWhenExpressionIsNotValid()
        {
            _expression = expression;

            Action action = () => CallCalculate();

            action
                .Should()
                .Throw<ArgumentException>();
        }

        private double CallCalculate()
        {
            var sut = Create();

            return sut
                .Calculate(
                    _expression
                );
        }

        private Calculator Create()
        {
            return new Calculator();
        }
    }
}

Settings for test generation

The default placement, naming, and location of the generated test may not suit everyone's preferences and requirements. Fortunately, all of these aspects can be easily customized to better align with your needs and tastes. Now, I will provide settings one by one. Settings for test generation are located in settings.json under the Test field. Here are the descriptions:

ClassSuffix - default value is Tests. This value determines the suffix added to the class's corresponding test class name. In the previous example for Calculator, it was CalculatorTests.
NameInMenu - default value is Test. This minor setting enables you to modify the name displayed in the Quick Actions menu. By default, it will be "Generate Test", but you can rename it to whatever you prefer. For instance, using the value "Unit Test" will result in "Generate Unit Test" as the menu item.
AssemblySpecificTargetProjectSuffix - default value is Tests. This setting instructs EasyTdd to place generated tests in the corresponding test project for each project. It will search for a project with the same name plus the predefined suffix. In the example above, Calculator is in the project ClassLibrary and the corresponding test project is ClassLibrary.Tests. This can be customized to suit individual preferences and requirements, such as prefixing the test project with UnitTests or something else. Within the test project, EasyTdd maintains the original folder hierarchy.
TargetProjectNameForAssembliesWithoutSpecificTargetProject - default value is null. This unusually long-named setting is used to specify a project name when it doesn't match the source project naming. For example, if I want to place all tests from all projects into a single test project called ClassLibrary.AllTests, I would set this setting to ClassLibrary.AllTests. In this case, I can leave AssemblySpecificTargetProjectSuffix with its default value, as EasyTdd will first try to find a project with the predefined suffix and then fall back to the value in TargetProjectNameForAssembliesWithoutSpecificTargetProject if it doesn't find one. If EasyTdd doesn't locate the project specified in TargetProjectNameForAssembliesWithoutSpecificTargetProject, it will place the test class next to the class being tested.
Folder - default value is null. For instance, if I choose to have a single project for all test-related components - including all tests, builders, test doubles, etc. - I might want to organize them in corresponding folders. If I set TargetProjectNameForAssembliesWithoutSpecificTargetProject to ClassLibrary.AllTestStuff and set Folder to Tests, then the test for ClassLibrary\Services\SomeService.cs will be placed in ClassLibrary.AllTestStuff\Tests\Services\SomeServiceTests.cs.
DefaultTestFramework - the default value is NUnit. EasyTdd attempts to identify the testing framework used in the target test project. If it fails to recognize the framework, it will use templates for the test framework specified here.
OutputSettings - this section contains configurations for NUnit, MsTest, and xUnit testing frameworks. Each configuration has the same structure, so I will provide an overview of the structure without focusing on a specific testing framework.
- FileTemplates - this section contains settings for the specific files that will be generated.
  - NameTemplate - default value is {{className}}.cs, where className refers to the name of the test class.
  - ContentTemplateFile - The default value depends on the testing framework. For NUnit, the default is nunit.test.tpl. If you need to change the template, create a copy and then modify the template file name here.
  - Recreate - default value is false. When a class already has a test file created, EasyTdd offers the options to "Open CalculatorTests.cs" and "Regenerate CalculatorTests.cs" instead of "Generate Test". In many cases, I don't want to regenerate the test file, so setting this value to false will hide the "Regenerate" options from the menu.
- ToolingNamespaces - by default, this contains a list of namespaces to support the tooling used in the default test template. Examples include Moq, FluentAssertions, and testing framework-specific namespaces. EasyTdd adds source class-related namespaces to the generated class, but it is not aware of the tooling used in the template itself. This is where you can define those namespaces.

Adapting the template

The default outcome, as seen in the Calculator example above, may not suit everyone's preferences. You might want to adapt it to better fit your needs. For instance, fields are prefixed with an underscore, FluentAssertion is used, and the namespace declaration follows the .NET framework style with curly braces. So, what can you do about that? If your project uses NUnit, for instance, copy .easyTdd/DefaultTemplates/nunit.test.tpl and paste it into a new location, such as .easyTdd/MyTemplates/nunit.test.tpl. Open the file with a text editor and make any necessary changes. The template is written in the Scriban scripting language. Please refer to the documentation for more information. As mentioned earlier, don't forget to update setting.json with the new template name. In this particular case, the Test.OutputSettings[NUnit].FileTemplates[0].ContentTemplateFile value should be changed to "mytemplates\\nunit.test.tpl".

Messing up with configuration

Since there is no UI for the configuration yet, it's easy to make mistakes with it. A source control system like Git can be helpful in this situation, but if the configuration files haven't been committed yet, feel free to delete the .easyTdd folder. It will be recreated with default settings the next time the solution is opened.

What's next?

This is just the beginning. In upcoming blog posts, I will demonstrate how to generate test case methods and classes for parameterized tests, as well as create builders and mocks. There are still a few features I'm working on:

Adding dependencies and generating all necessary test code to start working with a dependency easily.
Renaming/moving dependent files when the source file is renamed/moved. For example, if Calculate.cs is renamed to Calculator.cs, I want CalculateTests.cs to be automatically renamed to CalculatorTests.cs. Similarly, if I move Calculator.cs to the Services folder, I want CalculatorTests.cs to be moved to the Services folder in the test project as well.

In conclusion

I hope this blog post has been helpful. I've introduced one feature of EasyTdd - test class template generation - and explained how to configure this feature to suit your needs. Please feel free to ask questions and provide feedback.

Easy way to start TDD

Kazys — Sat, 27 Jan 2024 14:02:47 +0000

Hi, my name is Kazys Račkauskas, and this is my first blog post. I'm a back-end .NET developer specializing in C#, and I'm passionate about TDD and other testing approaches. Lately, I've been focusing heavily on E2E testing at work.

While reading numerous blog posts about TDD and testing in general, I've noticed various perspectives on the subject. These range from having no tests at all to employing a multitude of test-writing approaches. This not only includes different scopes like integration, acceptance, E2E, and unit tests, but also various styles within unit testing itself, including TDD. I won't judge any of these methods, as they are likely all perfectly valid depending on factors such as coding style, project scope, utilized technologies, personal preferences, and individual personalities. Instead, I will share my approach, which works well for me, aligns with my thought process, and is effective in most cases I encounter.

Why EasyTDD? When I first started with TDD, it was slow for a couple of reasons. Firstly, the learning curve wasn't very steep, so I had to internalize the process and develop my skills. Secondly, in many cases, the test code was larger than the production code, which felt a bit awkward. As a result, I began looking for ways to make the TDD process less time-consuming and more straightforward.

In this blog post, I will discuss why I chose the London-style TDD, the test structure, and the testing flow. Additionally, I will introduce my pet project - EasyTDD. EasyTDD is a tool designed to speed up the process of writing tests by generating test templates and other useful code snippets, making the TDD process faster. This Visual Studio Extension is tailored for C# users and can be downloaded via the Extension Manager or directly from the EasyTDD - Visual Studio Marketplace. Its primary focus is to enhance the TDD experience within the Visual Studio environment.

Some backing of style I use

There are two primary schools of TDD - Detroit (also known as Chicago, Classicists, inside-out, or black-box testing) and London (also known as Mockists, outside-in, or white-box testing). This seems like a classic rivalry, similar to Windows vs. Linux vs. Mac, iPhone vs. Android, functional programming vs. object-oriented programming, or perhaps even Tesla vs. other electric cars, among others. I won't delve deeply into the pros and cons here. For a comprehensive review of both approaches, consider the following recommended readings:

Detroit and London Schools of Test-Driven Development

Test Driven Development Wars: Detroit vs London, Classicist vs Mockist

Test-Driven-Development

Mocks Aren't Stubs

Alright, so in support of the London style, I work for a company that develops a product for the travel industry. When I started 10 years ago, it already had a significant amount of legacy code, and now the code I wrote a decade ago is considered legacy as well. To give you an idea, it's a massive solution, now comprising almost 100 projects, with numerous integrations, multiple stages of processing, rules, and so on. When I started, there were hardly any tests, and the ones that existed were incredibly slow. The functionality of the workflow depends on various factors - outputs from external sources, configurations, rules, etc. Setting up a test required a tremendous amount of work. We had an environment that was meant to simulate production but was painfully slow. That's where mocks came into play - it was like landing in the middle of a code jungle - determining where to place the new functionality, identifying dependencies, mocking those dependencies, writing tests, implementing, connecting to the jungle, and then leaving. Naturally, like a Boy Scout, I want to clean up the surroundings a bit, make it neater and better, and cover it with tests. However, I can't clean up the entire jungle; I have to stop somewhere. And where I stop, I find dependencies and mock them. That's it.

The text concerns legacy code. What about the new code? Yes, I apply the London style to the new code as well. Here are the main points I use to justify it for myself:

Outside-in, or top-down design process: This is just how my thinking works, starting with the big picture and gradually delving into the details. It helps me discover what is needed. There is a London-style branch called Discovery Testing. I'm not sure if it's an official name or how widely it's used, but reading this wiki aligns with my style of thinking: Discovery Testing · testdouble/contributing-tests Wiki · GitHub.
Deferring the decision: I don't want to delve too deeply into one aspect of the problem until I have a broader understanding of the overall picture. This approach is somewhat similar to Breadth-First Search for me.
SOLID object-oriented design (OOD) principles.
- Dependency inversion: This principle states that one should depend on abstractions. I trust that the abstraction will do its job, while concrete implementations are tested elsewhere.
- Liskov substitution principle: This principle states that a function or class must be able to use objects of derived classes without knowing it. A mock is a derived class, so I can use it, and the subject under test shouldn't know that.
- Single responsibility and interface segregation: Services and objects become quite small, making them easy to test. They will perform one function and have no side effects.

Are unit tests enough?

The short answer is that it depends. In some cases, unit tests are trivial and not necessary. In other instances, incorrect assumptions may be made about dependencies and their respective responsibilities, leading to malfunctions when the functionality is integrated. This is particularly true when multiple developers are working to implement the functionality. As a result, I prefer to cover the functionality with some level of integration testing.

The process of doing TDD

For those who are unfamiliar with it, TDD follows a simple mantra: red -> green -> refactor.

Red - Write a test for a piece of functionality you want to implement. The test should fail because no code covering the functionality has been written yet. If the test is green, something is wrong with the test.
Green - Write production code to cover the test case. Run the test; if it is green, proceed to the next step. If it is red, something is not right yet, either in the production code or in the test itself. Always consider that the test you wrote might contain bugs as well. If you don't see anything suspicious in the code, return to the test code and review it.
Refactor - Restructure the code to make it cleaner and more efficient. This also applies to the test code, as there might be duplicate logic in the tests, or some elements could be moved to helper methods or restructured. Treat test code as first-class citizens. Run the tests - they should still be green. If not, something went wrong and needs to be fixed. Once it is green again, start from the beginning.

How to start?

Does the test always come first? Based on the flow of actions described above, the test should come first, followed by the code. However, this can sometimes feel awkward to me. In most cases, I start by creating a class signature. Remember the top-to-bottom approach: the class signature has likely already been revealed in the form of an interface if it's not a top-level class.

So, I need a starting point. I need a name, whether it's for the test or the class. Sometimes, I feel stuck at this stage. It's a common saying that naming is one of the most challenging tasks for developers. If I can't think of anything relevant, it's okay for me to start with a class called SomeService and a method called DoSomething.

Let's say we have a classic calculator example: some input is provided, and the service needs to return the calculated result. To make it more challenging, let's assume that the input is a string, like "2+3", "3", "2+5.5+4-22", etc. However, for the sake of simplicity, let's say that it only accepts "+" and "-" as operations.

Test template

In my day-to-day work, I use FluentAssertions for assertions, so I incorporate them into my examples as well.

The pure TDD approach requires writing the test first, followed by the code. In this method, a class signature is created only after the tests demonstrate a need for it. However, I don't adhere to this rule. Instead, I create an empty class first, like this:

public class Calculator
{
    public double Calculate(string expression)
    {
        throw new NotImplementedException();
    }
}

Let's use EasyTdd to generate the test. Click on the "Quick action" icon or press Ctrl+. to access the quick action menu. Choose "Generate Test."

The tool will generate a test class and open it in Visual Studio. It will look something like this:

public class CalculatorTests
{
    private string _expression;

    [SetUp]
    public void Setup()
    {
        _expression = string.Empty;
    }

    [TestCase(null)]
    public void CalculateThrowsArgumentExceptionWhenExpressionIsNotValid()
    {
        _expression = expression;

        Action action = () => CallCalculate();

        action
            .Should()
            .Throw<ArgumentException>();
    }

    private double CallCalculate()
    {
        var sut = Create();

        return sut
            .Calculate(
                _expression
            );
    }

    private Calculator Create()
    {
        return new Calculator();
    }
}

Now, I have something to work with. Let's discuss what we have here:

_expression - I create a field for each input of the method I test.
Setup() - Here, I initialize input values, mocks, etc., with values typically used to pass the longest happy path.
Create() - This method creates a subject under the test. It is useful because I don't need to initialize the SUT with all dependencies in all tests.
CallCalculate() - This is responsible for calling the method in testing. It creates the SUT, provides all input parameters to the method in testing, and returns the value. Since each test has to do the same, I like to have it in one place.
ThrowsExceptionWhenExpressionIsInvalid - I always start with a test that establishes boundaries for the SUT (system under test). In many cases, provided values will never be used in the live system, but it is helpful for me while designing the class when I have clear boundaries, and it also serves as documentation.

Good to go, now I have runnable code. I can run the test, debug if needed, and see instant results on how it behaves.

At this point, there is no clear distinction between arrange-act-assert, but I will explain the reasoning later in a more complex example.

At this point, I have a failing test. Let's make it pass.

public class Calculator
{
    public double Calculate(string expression)
    {
        if (expression == null)
        {
            throw new ArgumentNullException(nameof(expression));
        }

        throw new NotImplementedException();
    }
}

The expression not being null is not the only boundary I want to establish. To make it more readable, I will add more TestCase attributes to the current test to cover all out-of-boundary cases. Most likely, I won't think of all the cases, so I will add new ones during the development process. I'll start with null, empty, and whitespace strings:

[TestCase(null)]
[TestCase("")]
[TestCase("  ")]
public void ThrowsExceptionWhenExpressionIsNull(string expression)
{
    _expression = expression;

    Action action = () => CallCalculate();

    action
        .Should()
        .Throw<ArgumentException>();
}

Here is the implementation:

public double Calculate(string expression)
{
    if (string.IsNullOrWhiteSpace(expression))
    {
        throw new ArgumentNullException(nameof(expression));
    }

    throw new NotImplementedException();
}

Now, I will add a test for single-number calculation:

[TestCase("3", 3)]
[TestCase("3.5", 3.5)]
public void ReturnsExpectedCalculatedExpression(
    string expression, 
    double expectedResult)
{
    _expression = expression;

    var result = CallCalculate();

    result
        .Should()
        .Be(expectedResult);
}

And the implementation:

public double Calculate(string expression)
{
    if (string.IsNullOrWhiteSpace(expression))
    {
        throw new ArgumentNullException(nameof(expression));
    }

    return double.Parse(expression, CultureInfo.InvariantCulture);
}

Step by step, I add cases for expected and boundary tests, implementing them in the same incremental manner. For brevity, I won't provide all the implementation steps here. Step-by-step implementations can be found at easyTdd/EasyWayToStartTDD (github.com). The final test class code appears as follows:

public class CalculatorTests
{
    private string _expression;

    [SetUp]
    public void Setup()
    {
        _expression = string.Empty;
    }

    [TestCase(null)]
    [TestCase("")]
    [TestCase("  ")]
    [TestCase("a")]
    [TestCase("aabb")]
    [TestCase("=")]
    [TestCase("+")]
    [TestCase("-")]
    [TestCase("35.21a")]
    [TestCase("a123")]
    public void ThrowsExceptionWhenExpressionIsInvalid(string expression)
    {
        _expression = expression;

        Action action = () => CallCalculate();

        action
            .Should()
            .Throw<ArgumentException>();
    }

    [TestCase("3", 3)]
    [TestCase("3.5", 3.5)]
    [TestCase("2+2", 4)]
    [TestCase("2.5+2", 4.5)]
    [TestCase("2.5+2.8", 5.3)]
    [TestCase("2.5-2", 0.5)]
    [TestCase("2.5-2.8", -0.3)]
    [TestCase("10+20-5.5+8-3+2.8", 32.3)]
    public void ReturnsExpectedCalculatedExpression(
        string expression, 
        double expectedResult)
    {
        _expression = expression;

        var result = CallCalculate();

        result
            .Should()
            .BeApproximately(expectedResult, 0.001);
    }

    private double CallCalculate()
    {
        var sut = Create();

        return sut
            .Calculate(
                _expression
            );
    }

    private Calculator Create()
    {
        return new Calculator();
    }
}

The calculator code appears as follows:

public class Calculator
{
    public double Calculate(string expression)
    {
        if (string.IsNullOrWhiteSpace(expression))
        {
            throw new ArgumentNullException(nameof(expression));
        }

        var regex = new Regex(@"^\d+(\.\d+)?((\+|\-)\d+(\.\d+)?)*$");

        if (!regex.IsMatch(expression))
        {
            throw new ArgumentException(
                $"'{expression}' is not valid expression."
            );
        }

        var tokens = Regex.Matches(expression, @"(\d+(\.\d+)?)|(\+|\-)");

        if (tokens.Count == 1)
        {
            return ParseDouble(tokens[0].Value);
        }

        var result = ParseDouble(tokens[0].Value);

        for (var i = 1; i < tokens.Count - 1; i += 2)
        {
            if (tokens[i].Value == "+")
            {
                result += ParseDouble(tokens[i + 1].Value);
            }
            else
            {
                result -= ParseDouble(tokens[i + 1].Value);
            }
        }

        return result;
    }

    private double ParseDouble(string value)
    {
        return double.Parse(
            tokens[i + 1].Value, 
            CultureInfo.InvariantCulture
        );
    }
}

More advanced example with test doubles

Now, I will present a more complex example to introduce other concepts I use while practicing TDD. Please note, that this example is intended for demonstration purposes and may not comprehensively cover business requirements or the optimal implementation strategy.

Let's assume that the task is to implement payment callback functionality. When a payment is completed, an external payment provider calls our endpoint to register the payment. The service has the following requirements:

The payment needs to be registered for the related invoice.
The event "Paid" should be published when the invoice is fully paid.
The event "PartiallyPaid" should be published when the paid amount is less than the invoice's total amount. It is possible that this is not the first payment, so the total paid should be compared to the invoice's total amount.
The event "UnexpectedPayment" should be published when the invoice becomes overpaid or when no invoice exists for the provided invoice number.

In this example, I assume that a message bus abstraction, IBus, already exists.

public interface IBus
{
    Task PublishAsync<TMessage>(TMessage message);
}

Outside-in

Now, I want to write that initially, I would create an end-to-end (e2e) test for this feature. However, I will skip it since the focus of this blog post is on unit tests. So, moving with the outside-in, as a C# developer, I will create an ApiController for the endpoint that will be called by an external system. The tests will start here and guide me on what else I need.

Let's assume that the payment provider outlines the requirements for the payment callback request structure, which is as follows:

public class PaymentCallbackRequest
{
    public string PaymentReference { get; set; }
    public string InvoiceNo { get; set; }
    public decimal AmountPaid { get; set; }
}

I will first create a controller class:

    [Route("api/[controller]")]
    [ApiController]
    public class PaymentController : ControllerBase
    {
        [HttpPost("callback")]
        public IActionResult Callback(PaymentCallbackRequest request)
        {
            throw new NotImplementedException();
        }
    }

Now, I will open the "Quick Actions" menu and select "Generate Test." To do this, the EasyTdd extension must be installed in Visual Studio.

Voilà - the test class is in place, runnable, and ready to be extended:

public class PaymentControllerTests
{
    private PaymentCallbackRequest _request;

    [SetUp]
    public void Setup()
    {
        _request = default;
    }

    [TestCase(null)]
    public void CallbackThrowsArgumentExceptionWhenRequestIsNotValid(
        PaymentCallbackRequest request)
    {
        _request = request;

        Action act = () => CallCallback();

        act
            .Should()
            .Throw<ArgumentException>();
    }

    private IActionResult CallCallback()
    {
        var sut = Create();

        return sut
            .Callback(
                _request
            );
    }

    private PaymentController Create()
    {
        return new PaymentController();
    }
}

As in the example above, I will begin with a boundary test. The [TestCase] attribute (correspondingly, [DataRow] in MsTest and [InlineData] in xUnit) can only accept primitive types, so I will modify this test to use the [TestCaseSource] attribute (MsTest and xUnit have the [DynamicData] and [MemberData] attributes, respectively). This enables me to provide any data type for each test case. As expected, I will utilize EasyTDD to assist me in this process. EasyTdd can generate either an in-class method or a separate class as a test case source. It also works with MsTest, NUnit, and xUnit. If the amount of test data is small, I use an in-class method as a test case source; otherwise, I opt for a separate class. Open the "Quick actions" menu on the boundary test signature, and two options will be visible there:

The following code has been generated:

    [TestCase(null)]
    [TestCaseSource(nameof(GetCallbackThrowsArgumentExceptionWhenRequestIsNotValidCases))]
    public void CallbackThrowsArgumentExceptionWhenRequestIsNotValid(
        PaymentCallbackRequest request)
    {
        _request = request;

        Action act = () => CallCallback();

        act
            .Should()
            .Throw<ArgumentException>();
    }

    private static IEnumerable<TestCaseData> GetCallbackThrowsArgumentExceptionWhenRequestIsNotValidCases()
    {
        yield return new TestCaseData(
                default //Set value for request
            )
            .SetName("[Test display name goes here]");

        yield return new TestCaseData(
                default //Set value for request
            )
            .SetName("[Test display name goes here]");
    }

I will remove the [TestCase(null)] from the test and modify it to expect a BadRequest result instead of an exception. For the sake of brevity, I will include only a few cases:

    [TestCaseSource(nameof(GetCallbackThrowsArgumentExceptionWhenRequestIsNotValidCases))]
    public void CallbackBadRequestWhenRequestIsNotValid(
        PaymentCallbackRequest request)
    {
        _request = request;

        var result = CallCallback();

        result
            .Should()
            .BeOfType<BadRequestResult>();
    }

    private static IEnumerable<TestCaseData> GetCallbackThrowsArgumentExceptionWhenRequestIsNotValidCases()
    {
        yield return new TestCaseData(
                new PaymentCallbackRequest
                {
                    PaymentReference = "xx",
                    InvoiceNo = "yy",
                    AmountPaid = -1
                }
            )
            .SetName("Amount is negative");

        yield return new TestCaseData(
                new PaymentCallbackRequest
                {
                    PaymentReference = "xx",
                    InvoiceNo = "",
                    AmountPaid = 10
                }
            )
            .SetName("InvoiceNo is not set");

        yield return new TestCaseData(
                new PaymentCallbackRequest
                {
                    PaymentReference = "",
                    InvoiceNo = "yy",
                    AmountPaid = 10
                }
            )
            .SetName("PaymentReference is not set");
    }

I ran those tests. They failed (red). Then, I wrote some code to make the tests pass:

        [HttpPost("callback")]
        public IActionResult Callback(PaymentCallbackRequest request)
        {
            if (request.AmountPaid < 0)
            {
                return BadRequest();
            }

            if (string.IsNullOrWhiteSpace(request.InvoiceNo))
            {
                return BadRequest();
            }

            if (string.IsNullOrWhiteSpace(request.PaymentReference))
            {
                return BadRequest();
            }

            throw new NotImplementedException();
        }

I'm running tests again - they're green. Now it's time for refactoring. I will move the validation to a separate method to make the main method cleaner and easier to read.

    [HttpPost("callback")]
    public IActionResult Callback(PaymentCallbackRequest request)
    {
        if (!IsRequestValid(request))
        {
            return BadRequest();
        }

        throw new NotImplementedException();
    }

    private static bool IsRequestValid(PaymentCallbackRequest request)
    {
        if (request.AmountPaid < 0)
        {
            return false;
        }

        if (string.IsNullOrWhiteSpace(request.InvoiceNo))
        {
            return false;
        }

        if (string.IsNullOrWhiteSpace(request.PaymentReference))
        {
            return false;
        }

        return true;
    }

Now, the application must register the payment and send the message. It is not the responsibility of this service to handle how the payment should be registered, so I will delegate this task to the IInvoiceRepository service. The name might not be ideal, but it will suffice for now, and I can change it later if necessary. I have the invoice number and paid amount, which need to be registered. RegisterPaymentAsync(string invoiceNo, decimal amount) seems like a suitable contract:

public interface IInvoiceRepository
{
    Task RegisterPaymentAsync(
        string invoiceNo,
        decimal amount
    );
}

The implementations of this service will handle the specifics - where and how this information will be stored. I will postpone the decision on how to implement it and focus on the PaymentController implementation for now. In the tests, I will use test doubles to replace IInvoiceRepository and IBus.

Test doubles

Test doubles are objects that facilitate testing by making it easier. In tests, we typically replace dependencies with test doubles to reduce complexity, increase test speed, simplify setup, and focus solely on the System Under Test (SUT) without distractions. Several similar terms represent different concepts, such as stubs, fakes, mocks, spies, and dummies. "Mock" has become somewhat of a generic term to describe all of these, likely due to the prevalence of mocking frameworks that cover most scenarios. Even practitioners of the London School of Test-Driven Development (TDD) are called "Mockists."

In both my professional work and personal hobby or pet projects, I use Moq. While there are other options available, the main features of these tools are more or less the same.

Happy path

I will begin by outlining the complete process of a happy path. After that, I will consider alternative routes. I ask myself - what should be the result of the payment callback? It must register the payment and send a Paid message. When an invoice is fully paid, the happy path would involve registering the payment and sending a "Paid" message:

What should I do first? Initially, I will set up the default request:

    [SetUp]
    public void Setup()
    {
        _request = new PaymentCallbackRequest
        {
            PaymentReference = "xx",
            InvoiceNo = "EASY0001",
            AmountPaid = 1000
        };
    }

The first test will ensure that the payment callback returns an "OK" status:

[Test]
public void ReturnsOKWhenInvoiceIsFullyPaid()
{
    var result = CallCallback();

    result
        .Should()
        .BeOfType<OkResult>();
}

I ran tests and they failed. Then, I wrote some code to make them pass:

[HttpPost("callback")]
public IActionResult Callback(PaymentCallbackRequest request)
{
    if (!IsRequestValid(request))
    {
        return BadRequest();
    }

    return Ok();
}

Nothing to refactor here. The next test would be to assert whether the payment was registered:

[Test]
public async Task PaymentIsRegisteredWhenInvoiceIsFullyPaid()
{
    await CallCallback();

    _invoiceRepositoryMock.Verify();
}

Now, it doesn't even compile. The mock needs to be declared, initialized, set, and passed into the constructor. Since IInvoiceRepository.RegisterPaymentAsync has a side effect and does not return a value, I can use either a spy or a mock test double to verify the call. For this service, I will use the mock variation.

private Mock<IInvoiceRepository> _invoiceRepositoryMock;
.
.
[SetUp]
public void Setup()
{
    .    
    .
    _invoiceRepositoryMock = new Mock<IInvoiceRepository>(MockBehavior.Strict);

    _invoiceRepositoryMock
        .Setup(
            x => x.RegisterPaymentAsync(
                "EASY0001",
                1000
            )
        )
        .Returns(Task.FromResult(0))
        .Verifiable(Times.Once);
}
.
.
private PaymentController Create()
{
    return new PaymentController(
        _invoiceRepositoryMock.Object
    );
}

Once again, I ran the test and it failed as expected. Now, I will write some code to make the test pass:

private readonly IInvoiceRepository _invoiceRepository;

public PaymentController(IInvoiceRepository invoiceRepository)
{
    _invoiceRepository = invoiceRepository;
}

[HttpPost("callback")]
public Task<IActionResult> Callback(PaymentCallbackRequest request)
{
    if (!IsRequestValid(request))
    {
        return BadRequest();
    }

    await _invoiceRepository
        .RegisterPaymentAsync(
            request.InvoiceNo,
            request.AmountPaid
        );

    return Ok();
}

Now, I need a test to verify whether IBus with the message Paid was called.

[Test]
public async Task PaidMessageIsSentWhenInvoiceIsFullyPaid()
{
    await CallCallback();

    _busMock
        .Verify(
            x => x.PublishAsync(
                It.Is<Paid>(x => x.InvoiceNo == "EASY0001")
            )
        );
}

Similar to _invoiceRepositoryMock, I'm required to declare _busMock, perform its initialization, set it up accordingly, and subsequently pass it to the constructor. IBus doesn't return any value but has a side effect - I can use a spy or a mock for it. In this example, I'll use the spy version of a test double.

private Mock<IBus> _busMock;
.
.
[SetUp]
public void Setup()
{
    .   
    .
    _busMock = new Mock<IBus>();

    _busMock
        .Setup(
            x => x.PublishAsync<Paid>(
                It.IsAny<Paid>()
            )
        );
}
.
.
private PaymentController Create()
{
    return new PaymentController(
        _invoiceRepositoryMock.Object,
        _busMock.Object
    );
}

I ran the test again, and it failed. Here is some code to make it pass:

[HttpPost("callback")]
public async Task<IActionResult> Callback(PaymentCallbackRequest request)
{
    if (!IsRequestValid(request))
    {
        return BadRequest();
    }

    await _invoiceRepository
        .RegisterPaymentAsync(
            request.InvoiceNo,
            request.AmountPaid
        );

    await _bus
        .PublishAsync(
            new Paid(request.InvoiceNo)
        );

    return Ok();
}

Other routes

I have the following test cases:

The invoice is fully paid with one payment - register the payment, send the Paid message.
The invoice is partially paid - register the payment, send the PartiallyPaid message.
The invoice has already been partially paid, and with the current request, it is fully paid - register the payment, send the Paid message.
Payment is made for an unknown invoice - do not register the payment, send the UnexpectedPayment message.
If the payment amount is larger than the invoice amount - do not register the payment, send the UnexpectedPayment message.
The partially paid invoice is overpaid with the current request - do not register the payment, send the UnexpectedPayment message.
Request received for an already paid invoice - do not register the payment, send the UnexpectedPayment message.

I won't cover all the cases here, as going step-by-step generates a lot of text. I'd like to introduce a few more concepts and then provide the complete code in a GitHub repository. I'll take some shortcuts here to reduce the amount of code.

First, I'd like to introduce the discovery of IInvoiceRepository.GetByInvoiceNoAsync. In the happy path scenario, I assumed that an invoice was always fully paid, so I simply registered the payment and sent the appropriate message. Now, I'll address the second case from the list. To determine if the invoice is fully or partially paid, I need to retrieve some data from storage. I've deferred the decision on how exactly this data is stored and retrieved by introducing the new method, IInvoiceRepository.GetByInvoiceNoAsync, and creating an Invoice class:

public class Invoice
{
    public Invoice(
        string invoiceNo, 
        decimal totalAmount,
        decimal paidAmount)
    {
        InvoiceNo = invoiceNo;
        TotalAmount = totalAmount;
        PaidAmount = paidAmount;
    }

    public string InvoiceNo { get; }
    public decimal TotalAmount { get; }
    public decimal PaidAmount { get; }
}

Setting up the GetByInvoiceNoAsync method, I would do something like this:

_invoiceRepositoryMock
    .Setup(x => x.GetByInvoiceNoAsync("EASY0001"))
    .ReturnsAsync(
        new Invoice("EASY0001", 1000, 0)
    );

The corresponding tests might appear as follows:


[Test]
public async Task PaymentIsRegisteredWhenInvoiceIsPartiallyPaid()
{
    _request.AmountPaid = 500;

    await CallCallback();

    _invoiceRepositoryMock
        .Verify();
}

[Test]
public async Task PartiallyPaidMessageIsSentWhenInvoiceIsPartiallyPaid()
{
    _request.AmountPaid = 500;

    await CallCallback();

    _busMock
        .Verify(
            x => x.PublishAsync(
                It.Is<PartiallyPaid>(x => x.InvoiceNo == "EASY0001")
            )
        );
}

And the code:

[HttpPost("callback")]
public async Task<IActionResult> Callback(PaymentCallbackRequest request)
{
    if (!IsRequestValid(request))
    {
        return BadRequest();
    }

    var invoice = await _invoiceRepository
        .GetByInvoiceNoAsync(request.InvoiceNo);

    await _invoiceRepository
        .RegisterPaymentAsync(
            request.InvoiceNo,
            request.AmountPaid
        );

    if (invoice.TotalAmount < request.AmountPaid)
    {
        await _bus
            .PublishAsync(
                new PartiallyPaid(request.InvoiceNo)
            );
    }
    else
    {
        await _bus
            .PublishAsync(
                new Paid(request.InvoiceNo)
            );
    }

    return Ok();
}

Although the test does not pass, it is because RegisterPaymentAsync is set to receive 1,000, but 500 is passed. Writing the setup for each dependency in every test can become quite wordy. It seems like it's time to introduce another concept - setting up a mock to return a reference instead of a specific object. To do this, I will use default values for all variables except the invoice from the repository. Instead of having separate requests, invoices, and mock setups for each case, I will only change the invoice. By having different values in the invoice object, I can simulate all the cases. To achieve this, I will modify the setup of IInvoiceRepository.GetByInvoiceNoAsync:

private Invoice _invoiceRepositoryResult;
[SetUp]
public void Setup()
{
.
.
    _invoiceRepositoryResult = new Invoice("EASY0001", 1000, 0);

    _invoiceRepositoryMock
        .Setup(x => x.GetByInvoiceNoAsync("EASY0001"))
        .ReturnsAsync(
            () => _invoiceRepositoryResult
        );
.
.

And now, tests for a partially-paid case will appear as follows:

[Test]
public async Task PaymentIsRegisteredWhenInvoiceIsFullyPaid()
{
    _invoiceRepositoryResult = new Invoice("EASY0001", 1500, 0);

    await CallCallback();

    _invoiceRepositoryMock
        .Verify();
}

[Test]
public async Task PartiallyPaidMessageIsSentWhenInvoiceIsPartiallyPaid()
{
    _invoiceRepositoryResult = new Invoice("EASY0001", 1500, 0);

    await CallCallback();

    _busMock
        .Verify(
            x => x.PublishAsync(
                It.Is<PartiallyPaid>(x => x.InvoiceNo == "EASY0001")
            )
        );
}

The PartiallyPaidMessageIsSentWhenInvoiceIsPartiallyPaid test is still failing. Hmm.. It appears I made a mistake in the code - the condition (invoice.TotalAmount < request.AmountPaid) should be changed to (invoice.TotalAmount > request.AmountPaid). I have corrected this, and now the tests are passing - hooray!

Test case bundling

For now, it appears that each test case from the list in the above segment will generate a few tests - one to assert IBus, one to assert IInvoiceRepository, and likely one more to test the result. However, I can bundle these to produce less code. IInvoiceRepository needs to be called in some cases and not called in others. I will have two tests for that with Invoice as a parameter:

[Test]
public async Task PaymentIsRegisteredWhenInvoiceIsPaid(
    Invoice invoice)
{
    _invoiceRepositoryResult = invoice;

    await CallCallback();

    _invoiceRepositoryMock
        .Verify();
}

Now, I will utilize the EasyTdd feature, "Generate Test Cases in External File":

This action generates a PaymentIsRegisteredWhenInvoiceIsPaidCases file, where I can include all the cases when RegisterPaymentAsync needs to be called:

public class PaymentIsRegisteredWhenInvoiceIsPaidCases : IEnumerable
{
    public IEnumerator GetEnumerator()
    {
        yield return new TestCaseData(
                new Invoice("EASY0001", 1000, 0)
            )
            .SetName("Invoice is fully paid");

        yield return new TestCaseData(
                new Invoice("EASY0001", 1500, 0)
            )
            .SetName("Invoice is partially paid");

        yield return new TestCaseData(
                new Invoice("EASY0001", 1500, 500)
            )
            .SetName("Partially paid invoice is fully paid");

        yield return new TestCaseData(
                new Invoice("EASY0001", 1500, 100)
            )
            .SetName("Partially paid invoice is partially paid");
    }
}

The same applies to other assertions as well. As previously mentioned, I will not delve into the details in this post, but instead, I will provide step-by-step commits in the following GitHub repository.

Some notes from the commit history

I am pleased that I managed to catch two bugs while implementing these examples, which were identified by running the tests. The first bug, which I mentioned earlier, involved mixing up < and >. The fix for this issue can be found in the commit [2e3a6b2]. The second bug can be found in the commit [8ba3718], where I mistakenly used invoice.TotalAmount instead of invoice.PaidAmount in an if statement.

Another important point is the rule of having a failing test first. It is crucial to start with a failing test, as it is possible to make mistakes in the test itself. One instance where I encountered this issue was in the commit [fb27deb], with the fix provided in [783e9a9]. In this situation, when bundling test cases, I used the existing test and added new cases. However, I mistakenly used the same old invoice value for all tests, neglecting the new cases. If I hadn't run the test and received a green light, I might have overlooked the error in the test and potentially forgotten to write code for those specific cases.

Arrange-Act-Assert

As it is known, the Arrange part is where we prepare the System Under Test (SUT) for acting, the Act is when we instruct the SUT to act, and the Assert is when we assess whether the SUT did what it was intended to do. I think that not all parts are clearly distinguished, especially Arrange. One part of Arrange is in the setup method, where test doubles are created and default values are set. Then, there's the test itself, where default values are changed to simulate other test cases. Finally, inside the CallCallback, the SUT is created with all its dependencies, and the request is provided to the method under test. It might look awkward and overly complex at first, but I found that it produces less code for me and helps me avoid code duplication. I could identify such points about the setting:

Create a field for each input parameter
Create a field for each test double
Create a field for each result of the test double
Set those fields up to satisfy a specific test case (happy path, longest path, or some other path)

Many test cases can be covered by changing one or a couple of fields from the list above.

I will not delve deeper into Act, as it is straightforward. Regarding Assert, I can add that assertions can leak into the test cleanup method. For example, mocks could be verified thereby calling Verify, or all mocks can be verified by calling the mock repository. I usually do not do this, as I prefer the spy version of test doubles.

Conclusion

In wrapping up, this blog post marks my initial venture into writing, and its completion required considerable time and effort. While it might seem lengthy, my intention was to establish a strong foundation for future writings and discussions. I've introduced my take on Test-Driven Development (TDD), focusing on the London-style approach and the practical use of test doubles. Throughout the post, I've demonstrated TDD in various scenarios, from a basic calculator to a more complex payment callback functionality. Emphasizing the significance of initiating tests that fail initially and following the Arrange-Act-Assert pattern, I've aimed to offer a comprehensive view of TDD principles. Lastly, I've introduced EasyTDD, my Visual Studio Extension designed to simplify the TDD process. This post serves as an opportunity to seek feedback on my TDD approach and to introduce EasyTDD to the developer community.