DEV Community: Juan Blasco

COURTROOM NO. 2 — THEO VS. UNIT TESTING: JUSTICE OR MISJUDGMENT?

Juan Blasco — Sun, 09 Mar 2025 19:18:41 +0000

COURTROOM NO. 2 — THEO VS. UNIT TESTING: JUSTICE OR MISJUDGMENT?

Judge: This court is now in session! Today, we examine Unit Testing, accused by Theo of slowing developers down unnecessarily!

Miles Assertion (Prosecutor): Ready to prosecute, Your Honor! Unit testing stands accused of sabotaging productivity — wasting valuable developer time!

Testin Wright (Defense Attorney): The defense is ready to prove the innocence of unit testing, Your Honor!

THE CASE: HAS UNIT TESTING GONE TOO FAR?

Miles Assertion: Ladies and gentlemen of the jury, Theo — a respected voice in web development — claims unit tests are inherently designed to slow developers down!

Allow me to present Exhibit A, Theo’s dramatic testimony in his video “Why I Don’t Unit Test”:

“Unit tests deliberately slow you down!”
“Fixing occasional bugs after deployment is cheaper!”
“Guard rails (unit tests) can’t predict every path — it’s futile!”
“Obsessive coverage numbers create false confidence!”

Theo boldly advises replacing excessive testing with quick recovery strategies, implying tests indicate code fragility and advocating rapid rollbacks instead.

Your Honor, unit tests may promise confidence, but do they truly deliver it? I argue they merely mask issues, causing more harm than good!

Testin Wright:

OBJECTION!

The prosecution’s accusations completely misunderstand the core purpose of unit testing!

Theo mistakenly targets poorly written tests , not proper behavioral unit tests!

Judge: Clarify immediately, Mr. Wright!

Testin Wright: Gladly, Your Honor! The defense asserts:

Unit tests document clear expectations — a treasure map guiding developers through complex systems!
Behavior tests reduce long-term manual labor , saving developers countless hours!
Behavioral vs. Implementation Tests : Behavioral tests stay reliable as long as the functionality remains consistent. Implementation tests, however, focus too heavily on mocks and internal details and are inherently fragile!

The prosecution’s argument is against fragile tests, NOT against unit testing itself!

Miles Assertion: OBJECTION! Theo explicitly says unit tests slow down projects!

Testin Wright: Slams desk dramatically Exactly! And the culprit isn’t unit testing — it’s poor testing strategy!

Miles Assertion: But isn’t it quicker and cheaper to simply handle issues post-deployment?

Testin Wright: Short-term maybe, but long-term disaster awaits! Without proper tests, developers will drown in endless manual testing, exhausting debugging marathons, and frantic patchwork fixes!

CROSS-EXAMINATION

Judge: Mr. Assertion, are you suggesting we abandon all testing?

Miles Assertion: Not abandon entirely, Your Honor, but Theo suggests minimizing reliance on exhaustive unit testing!

Testin Wright: Yet Theo misses the crucial nuance: it’s not about how many tests you write, but about the quality and purpose of those tests!

Properly used, unit tests provide clear, reliable checkpoints — helping developers navigate code safely and efficiently.

HOW TO WRITE EFFECTIVE UNIT TESTS

Judge: Mr. Wright, you’ve convinced this court that unit tests have value — but how should developers write them effectively?

Testin Wright: Excellent question, Your Honor! The defense presents Exhibit B, Ian Cooper’s enlightening testimony from the video “TDD, Where Did It All Go Wrong”:

According to Ian Cooper, developers commonly mistake two fundamentally different types of tests as unit tests:

Real Unit Tests (Behavioral Tests): These tests validate the behavior of the system, ensuring the system continues working correctly even if implementation details change. These tests rarely break and are valuable for long-term maintenance.
Implementation Tests : These focus heavily on internal structures and mocks, becoming brittle as soon as implementation details change. They’re useful during initial development but become a burden during maintenance.

The defense advises developers:

Test behaviors, not implementations :

Ensure tests validate “what” the code should accomplish, not “how” it achieves it internally.

2. View excessive mocking as a code smell :

Excessive mocks indicate overly coupled systems; use that as feedback to refactor.

3. Treat large amounts of tests around a single unit as a code smell :

If many tests are required for one unit, it’s likely too complex or tightly coupled. Break it down into simpler, isolated responsibilities.

4. Regularly review your test suite :

Maintain only the behavioral tests, which remain valid even when internal implementations change.
Don’t waste time maintaining implementation tests after achieving stability — they’ve served their purpose!

By clearly distinguishing between behavioral and implementation tests, unit tests become a powerful ally rather than a productivity burden!

FINAL VERDICT

Judge: After careful deliberation:

Behavioral unit tests provide design feedback, fast iteration, and documentation.
Implementation tests are useful temporarily but shouldn’t be maintained long-term.
Quick rollback and recovery strategies are essential complements — not replacements — to effective testing.

Verdict:

🔨 Unit Testing is found NOT GUILTY of intentionally wasting developers’ time! 🔨

The real issue: Misunderstood testing practices!

This court urges developers to:

✅ Emphasize behavioral unit tests for desgin feedbak, documentaiton and maintainable code.

✅ Minimize implementation tests , using them as a tool to speed up implementation.

✅ Prioritize robust recovery strategies alongside testing.

❌ Avoid obsessing over arbitrary coverage metrics!

Court is adjourned!

[CASE CLOSED — JUSTICE FOR TESTS DELIVERED!]

Final Notes

Theo highlights valid frustrations about testing pitfalls, but the solution is improving testing strategy — not abandoning it entirely!

Feedback and lively debate welcomed!

COURTROOM NO. 1 — THE CASE OF TDD: TRUTH OR TRAVESTY?

Juan Blasco — Thu, 27 Feb 2025 18:13:15 +0000

COURTROOM NO. 1 — THE CASE OF TDD: TRUTH OR TRAVESTY?

Judge: Court is now in session for the trial of Test-Driven Development, accused of wasting developers’ time with excessive unit tests!

Testin Wright (Defense Attorney for TDD): The defense is ready, Your Honor!

Prosecutor Miles Assertion: The prosecution is also ready. Today, we will prove that writing too many unit tests is a waste of time and does not provide true assurance of a functioning system!

THE CASE: TEST-DRIVEN DEVELOPMENT ON TRIAL

Miles Assertion: Ladies and gentlemen of the jury, we have gathered here today to address a serious crime in the world of software development: the blind pursuit of unit test coverage!

Consider the evidence presented in Web Dev Simplified’s video :

Unit Tests: Test a single function in isolation.
Integration Tests: Ensure components work together, but not the entire app.
End-to-End (E2E) Tests: Simulate real user interactions.

[Web Dev Simplified’s “Stop Writing So Many Tests” video added to the Court Record]

Developers, under the influence of Test-Driven Development, write excessive unit tests because they are easy to write. But instead of gaining true confidence in their systems, they waste valuable time mocking and faking everything!

I submit to the court that 100% unit test coverage does not mean a 100% functional system! If a test only verifies a function but never ensures the entire system runs smoothly, what is the point?

Your Honor, I call for a guilty verdict on TDD’s overreliance on unit tests!

Testin Wright:

OBJECTION!!

Your Honor, the prosecution’s argument lacks critical understanding of what testing is truly about!

They claim that TDD wastes time , but they fail to see that testing serves multiple goals, not just functional assurance.

THE DEFENSE PRESENTS THE FOLLOWING FACTS:

Tests improve code quality : Writing tests forces developers to think critically about their code structure.
Tests document expected behavior : A well-written test suite serves as living documentation!
Tests assure correct functionality : Yes, E2E tests provide the best overall assurance, but unit tests provide fast, focused feedback!

Your Honor, the prosecution is oversimplifying the value of unit tests.

Miles Assertion: But Mr. Wright, if developers are forced to write endless mocks, aren’t they wasting their time?

Testin Wright: If a developer is writing too many mocks , that is not an indictment of unit testing — it is a sign of a poor code design!

Judge: Order in the court! This is a heated debate. Mr. Wright, are you saying that unit tests still hold value despite their limitations?

Testin Wright: Exactly, Your Honor! The prosecution argues that E2E tests alone are the solution, but E2E tests are not a silver bullet!

Miles Assertion: OBJECTION! E2E tests provide the best assurance. Isn’t that what matters?

Testin Wright: Slams desk Not entirely! While E2E tests do provide the most realistic assurance, they:

Are slow and expensive to run compared to unit tests.
Make it harder to pinpoint failures when things break.
Cannot replace the need for thoughtful software design!

If developers abandon unit testing in favor of only E2E tests, they will find themselves debugging massive failures instead of catching issues early.

Your Honor, I submit that TDD is NOT GUILTY of wasting developers’ time. Instead, the real culprit is misunderstood testing strategy!

FINAL VERDICT

Judge: After hearing both arguments, I hereby declare:

🔨 TDD is NOT GUILTY! 🔨

However, I caution developers: do not chase 100% code coverage blindly. Instead, use the right test for the right purpose :

✅ Unit tests for fast, focused feedback and better design.

✅ Integration tests for ensuring components work together.

✅ E2E tests for full-system assurance but in moderation.

Court is adjourned!

[THE END — CASE CLOSED]

Final Notes

Recently, I’ve noticed a growing trend of content creators voicing strong opinions against unit testing and TDD. However, my team’s experience has been transformational — before and after adopting Continuous Delivery and TDD, we’ve found it to be the most effective approach for managing maintainable software.

With this fictional series, I aim to explore and engage with popular critiques of TDD, presenting counterarguments in a way that is both entertaining and thought-provoking.

Feedback and discussion is more than welcome!

Continuous Delivery and TDD Series — Kata 2

Juan Blasco — Sun, 16 Feb 2025 13:00:27 +0000

Continuous Delivery and TDD Series — Kata 2

Following the introduction in Kata 1, we now move on to Kata 2.

During the implementation of this Kata we will experience some key ideas:

Tests provide valuable feedback signals about code design.
Unlike manual tests, automated tests can be version-controlled and continuously improved, creating a positive feedback loop.
Test-driven development (TDD) is a fantastic way to guide LLM-generated code.

Ok, so let’s get started. Our goal is to create a simple calculator that takes a string as input and returns an integer. The calculator method is defined with a signature similar to:

int Add(string numbers)

Requirement 1

Handle Up to Two Numbers Initially, the method should accept up to two numbers separated by commas and return their sum. For example, the valid inputs are an empty string, “1”, or “1,2”. When provided an empty string, the method should return 0.

It is essential to capture this requirement through tests. Ideally, each test should assert a single behavior so that when a test fails, it points directly to the issue without having to dig through complex code. Think of each small test as a precise measurement, giving us clear insights into what might be wrong.

We start with the simplest case — an empty string:

[Test]
public void GivenAnEmptyString_ItReturnsZero()
{
    var calculator = new SimpleCalculator();
    var result = calculator.Add("");
    Assert.AreEqual(0, result);
}

A the most simple implementation we can come up with:

namespace TDDKata;

public class SimpleCalculator
{
    public int Add(string input) {
        return 0;
    }
}

Nothing much to refactor, let’s move on to the next test:

[Test]
public void GivenASingleNumber_ItReturnsThatNumberAsInt()
{
    var calculator = new SimpleCalculator();
    var result = calculator.Add("3");
    Assert.AreEqual(3, result);
}

Time to figure out how to implent this. Ok, so it seems that in C# we have an int.tryParse, we can use that, and actually also get the behaviour of the previous test case:

public int Add(string input)
{
    bool success = int.TryParse(input, out var result);
    return success ? result : 0;
}

Tests passing and nothing to refactor, we can now move on to a test where the input consists of two numbers separated by a comma, expecting their sum as the output.

[Test]
public void GivenAStringOfTwoNumberSeparatedByComas_ThenItReturnsTheSumAsInt()
{
    var calculator = new SimpleCalculator();
    var result = calculator.Add("1, 2");
    Assert.AreEqual(3, result);
}

Something like this seems to work:

public static int Add(string input)
{
   var numbers = input.Split(',');
    foreach (var number in numbers)
    {
        bool success = int.TryParse(number.Trim(), out var result);
        if (!success)
            {
                return 0;
            }
        }
        return numbers.Sum(int.Parse);
    }
}

And with these three test we have capture the initial first requirement!

As complexity grows, we will little by little feel the power of having our simple tests in our back, allowing us to restructure our code as much as we want.

Requirement 2

Allow the add method to handle an unknown number of arguments

Our initial implementation already allows for an unknown number of arguments. Let’s just make sure that we are capturing this behaviour in our tets. To make our tests more maintainable, we can use a parameterized test approach. This method reduces repetition by ensuring that only the inputs and expected results change between tests.

public class TestSimpleCalculator
{
    [TestCase("", 0)]
    [TestCase("3", 3)]
    [TestCase("1, 2", 3)]
    [TestCase("1, 2, 3, 4, 5", 15)]
    public void GivenAStringInput_ItReturnsTheExpectedResult(string input, int expected)
    {
        var result = SimpleCalculator.Add(input);
        Assert.AreEqual(expected, result);
    }
}

All test passing, I don’t see any obvious potential refactor gains, so let’s continue.

Requirement 3

Allow the add method to handle newlines as separators, instead of comas. Example: “1,2\n3” should return “6”

Our current setup allows to add this test fairly easily

public class TestSimpleCalculator
{
    [TestCase("", 0)]
    [TestCase("3", 3)]
    [TestCase("0, 1", 1)]
    [TestCase("1, 2", 3)]
    [TestCase("1, 2, 3, 4, 5", 15)]
    [TestCase("1, 2 \n 5", 8)]
    public void GivenAStringInput_ItReturnsTheExpectedResult(string input, int expected)
    {
        var result = SimpleCalculator.Add(input);
        Assert.That(result, Is.EqualTo(expected));
    }
}

Test failing, time for a simple implementation:

public static int Add(string input)
{
    var numbers = input.Split([',', '\n']);
    foreach (var number in numbers)
    {
        bool success = int.TryParse(number.Trim(), out var result);
        if (!success)
        {
            return 0;
        }
    }
    return numbers.Sum(int.Parse);
}

Refactor time — now it’s a little more obvious that this function is probably doing too many things. On one hand, it handles string preparation and parsing; on the other, it performs the actual calculation. We can tidy it up by splitting these responsibilities into different functions, which would be easier to maintain.

Here, we begin to feel the power of TDD. We can experiment and iterate with great safety, without needing extensive manual checks to confirm that our implementation works — our automated tests handle that for us.

Nowadays, this approach becomes even more valuable given how easy it is to generate code with LLMs. For example, here is a more modular proposal from ChatGPT-4.

public static int Add(string input)
{
    bool success = GetNumbers(input, out var numbers);
    if (numbers.Count() == 0)
        {
            return 0;
        }
        return numbers.Sum();
    }
}

private static bool GetNumbers(string input, out IEnumerable<int> numbers)
{
    numbers = input.Split([',', '\n'])
                   .Select(number => int.TryParse(number.Trim(), out var result) ? (int?)result : null)
                   .Where(n => n.HasValue)
                   .Select(static n => n.GetValueOrDefault());
    return true;
}

We can run our tets to verify that is a valid implementation to our problem! We don’t need to be afraid of hallucinations as far as we have tests that prove that a given piece of code is valid.

Back to the code, I like some of the ideas, and ChatGPT-4 is definitely more eloquent with LINQ than I am. I can now apply my personal preferences based on my standards of clean code and maintainability. Here is the final result, which I’m happy enough with to move on.

namespace TDDKata;

public class SimpleCalculator
{
    public static bool Add(string input, out int result)
    {
        bool success = GetNumbers(input, out var numbers);
        if (!success)
        {
            result = 0;
            return false;
        }
        if (numbers.Count() == 0)
        {
            result = 0;
            return true;
        }
        result = numbers.Sum();
        return true;
    }

    private static bool GetNumbers(string input, out IEnumerable<int> numbers)
    {
        var maybeParsedNumbers = input.Split([',', '\n'])
                       .Select(static number => int.TryParse(number.Trim(), out var result) ? (int?)result : null);
        if (maybeParsedNumbers.Any(static n => n == null))
        {
            numbers = Enumerable.Empty<int>();
            return false;
        }
        numbers = maybeParsedNumbers.Select(n => n.GetValueOrDefault());
        return true;
    }
}

I’ve decided to slightly change the interface to be more similar to that of TryParse; therefore, the test had to be updated. It’s important to note that tests only change when we modify the external interface.

namespace TDDKata.Tests;

public class TestSimpleCalculator
{
    [TestCase("", 0)]
    [TestCase("3", 3)]
    [TestCase("0, 1", 1)]
    [TestCase("1, 2", 3)]
    [TestCase("1, 2, 3, 4, 5", 15)]
    [TestCase("1, 2 \n 5", 8)]
    public void GivenAStringInput_ItReturnsTheExpectedResult(string input, int expected)
    {
        SimpleCalculator.Add(input, out var result);
        Assert.That(result, Is.EqualTo(expected));
    }
}

Requirement 4

Add validation to disallow a separator at the end.

While working on one requirement, it’s possible to break previous ones. For example, I broke the requirement that an empty string returns success and 0. Having tests makes it easier to debug and iterate. It was particularly useful to connect the VSCode debugger during the process.

How to connect with the VSCode C# debugger

In VSCode it’s as simple as:

If you select the Test solution, the run test icon will appear next to each test. Right-clicking (or holding Alt) shows the option to run them in debug mode, which will stop at the breakpoints you set.

After some iterations, the code took this shape.

namespace TDDKata.Tests;

public class TestSimpleCalculator
{
    [TestCase("", 0)]
    [TestCase("3", 3)]
    [TestCase("0, 1", 1)]
    [TestCase("0, 1", 1)]
    [TestCase("1, 2", 3)]
    [TestCase("1, 2, 3, 4, 5", 15)]
    [TestCase("1,2, 3,4, 5", 15)]
    [TestCase("1, 2 \n 5", 8)]
    public void GivenAStringInput_ThenItReturnsTheExpectedResult(string input, int expected)
    {
        var success = SimpleCalculator.Add(input, out var result);
        Assert.That(success, Is.True);
        Assert.That(result, Is.EqualTo(expected));
    }

    [TestCase("1,2,")]
    [TestCase("1, 2,\n")]
    [TestCase("1,2\n")]
    public void GivenAStringInputWithASeparatorAtTheEnd_ThenReturnsFalse(string input)
    {
        var success = SimpleCalculator.Add(input, out var result);
        Assert.That(success, Is.False);
    }
}

namespace TDDKata;

public class SimpleCalculator
{
    public static bool Add(string input, out int result)
    {
        if (!IsInputStringValid(input))
        {
            result = 0;
            return false;
        }
        bool success = GetNumbers(input, out var numbers);
        if (!success)
        {
            result = 0;
            return false;
        }
        result = numbers.Sum();
        return true;
    }

    private static readonly char[] _Separators = [',', '\n'];

    private static bool IsInputStringValid(string input)
    {
        if (input.Length == 0) return true;
        var lastChar = input.Last();
        return !_Separators.Contains(lastChar);
    }

    private static bool GetNumbers(string input, out IEnumerable<int> numbers)
    {
        var maybeParsedNumbers = input
            .Split(_Separators)
            .Select(x => x.Trim())
            .Where(static n => !string.IsNullOrWhiteSpace(n))
            .Select(static number => int.TryParse(number.Trim(), out var result) ? (int?)result : null);
        // Return false if any of the numbers could not be parsed
        if (maybeParsedNumbers.Any(static n => n == null))
        {
            numbers = [];
            return false;
        }
        numbers = maybeParsedNumbers.Select(n => n.GetValueOrDefault());
        return true;
    }
}

Requirement 5

Allow the add method to handle different delimiters

While we add more tests, and it’s important to appreciate that our test code also improves. We may learn new techniques, find ways to avoid repetition in our tests, or discover methods to speed up the testing process. Our test code continues to evolve. When we rely solely on manual testing, we lose the benefits of this positive feedback loop.

It is much more difficult to maintain version control and track improvements with manual tests (and we also lose more time executing them), whereas code does not have these downsides. We can iterate and improve continuously. This is the same reason why infrastructure as code is far more powerful than manual infrastructure management. Nevertheless, it’s always a trade-off, as there is obviously some overhead in developing tests. In my experience, this overhead is easily recovered. Still, it’s important to understand what we are sacrificing when making trade-offs. The more skilled you become at writing tests, the more often the trade-off will point towards automated testing.

[TestCase("//;\n1;2", 3)]
public void GivenAStringInputWithCustomSeparator_ThenItReturnsTheSum(string input, int expected)
{
    var success = SimpleCalculator.Add(input, out var result);
    Assert.Multiple(() =>
    {
        Assert.That(success, Is.True);
        Assert.That(result, Is.EqualTo(expected));
    });
}

Code implementation:

namespace TDDKata;

public class SimpleCalculator
{
    private static readonly char[] _DefaultSeparators = [',', '\n'];

    public static bool Add(string input, out int result)
    {
        if (!IsInputStringValid(input))
        {
            result = 0;
            return false;
        }
        ParseCustomSeparator(input, out string calculationInput, out char[] separators);
        bool success = GetNumbers(calculationInput, separators, out var numbers);
        if (!success)
        {
            result = 0;
            return false;
        }
        result = numbers.Sum();
        return true;
    }

    private static void ParseCustomSeparator(string input, out string calculationInput, out char[] separators)
    {
        bool hasCustomSeparator =
            input.Length > 4 && input[0] == '/' && input[1] == '/' && input[3] == '\n';
        if (!hasCustomSeparator)
        {
            separators = _DefaultSeparators;
            calculationInput = input;
            return;
        }
        separators = [input[2]];
        calculationInput = input[4..];
    }

    private static bool IsInputStringValid(string input)
    {
        if (input.Length == 0) return true;
        var lastChar = input.Last();
        return !_DefaultSeparators.Contains(lastChar);
    }

    private static bool GetNumbers(string input, char[] separators, out IEnumerable<int> numbers)
    {
        var maybeParsedNumbers = input
            .Split(separators)
            .Select(x => x.Trim())
            .Where(static n => !string.IsNullOrWhiteSpace(n))
            .Select(static number => int.TryParse(number.Trim(), out var result) ? (int?)result : null);
        // Return false if any of the numbers could not be parsed
        if (maybeParsedNumbers.Any(static n => n == null))
        {
            numbers = [];
            return false;
        }
        numbers = maybeParsedNumbers.Select(n => n.GetValueOrDefault());
        return true;
    }
}

Time to do some refactoring! I don’t like having to validate input strings directly, it gives too much work to the Add class of the calculator; in these cases, I prefer using the Value Object Pattern. The requirements force us to accept a string as input, but we can also provide a simple implicit conversion from string to our SimpleCalculatorInput, so that our tests calling the interface with a string won’t need to be changed.

Notice how we can also separate the testing. When a class requires extensive testing, it’s usually a sign that it is handling too many responsibilities. Over time, this can make maintenance increasingly difficult. By splitting input parsing and validation into a separate sub-problem, we simplify the calculator and improve maintainability.

Final Version

Final version for the tests:

namespace TDDKata.Tests;

public class TestSimpleCalculator
{

    [Test]
    public void GivenASimpleCalculatorInput_WhenAddIsCalled_ItReturnsTheSum()
    {
        var input = new SimpleCalculatorInput([1, 2, 3]);
        var success = SimpleCalculator.Add(input, out var result);
        Assert.Multiple(() =>
        {
            Assert.That(success, Is.True);
            Assert.That(result, Is.EqualTo(6));
        });
    }
}

public class TestSimpleCalculatorInput
{

    [Test]
    public void GivenAnEmptyInputString_ThenItReturnsIsValidTrueAndEmptyNumbers()
    {
        var input = SimpleCalculatorInput.Create("");
        Assert.Multiple(() =>
        {
            Assert.That(input.IsValid, Is.True);
            Assert.That(input.Numbers, Is.Empty);
        });
    }

    [TestCase("1,2,3", new int[] { 1, 2, 3 })]
    [TestCase("1\n2\n3", new int[] { 1, 2, 3 })]
    [TestCase("1\n2,3", new int[] { 1, 2, 3 })]
    public void GivenAStringUsingDefaultSeparators_ThenItReturnsIsValidAndTheNumbers(
        string inputString, int[] numbers)
    {
        var input = SimpleCalculatorInput.Create(inputString);
        Assert.Multiple(() =>
        {
            Assert.That(input.IsValid, Is.True);
            Assert.That(input.Numbers, Is.EqualTo(numbers));
        });
    }

    [TestCase("1,2,3,")]
    [TestCase("1,2,3\n")]
    [TestCase("//;\n1,2;3;")]
    public void GivenAStringWithASeparatorAtTheEnd_ThenItReturnsIsValidFalse(
        string inputString)
    {
        var input = SimpleCalculatorInput.Create(inputString);
        Assert.Multiple(() =>
        {
            Assert.That(input.IsValid, Is.False);
            Assert.That(input.Numbers, Is.Empty);
        });
    }

    [TestCase("//;\n1;2;3", new int[] { 1, 2, 3 })]
    [TestCase("//;\n1,2;3", new int[] { 1, 2, 3 })]
    public void GivenACustomSeparator_ThenItReturnsTheExpectedNumbers(
        string inputString, int[] numbers)
    {
        var input = SimpleCalculatorInput.Create(inputString);
        Assert.Multiple(() =>
        {
            Assert.That(input.IsValid, Is.True);
            Assert.That(input.Numbers, Is.EqualTo(numbers));
        });
    }
}

public class TestSimpleCalculatorRequirements
{

    [TestCase("", 0)]
    [TestCase("3", 3)]
    [TestCase("0, 1", 1)]
    [TestCase("0,1", 1)]
    [TestCase("\n0,1", 1)]
    [TestCase("1, 2", 3)]
    [TestCase("1, 2, 3, 4, 5", 15)]
    [TestCase("1,2, 3,4, 5", 15)]
    [TestCase("1, 2 \n 5", 8)]
    public void GivenAStringInput_ThenItReturnsTheSum(string input, int expected)
    {
        var success = SimpleCalculator.Add(input, out var result);
        Assert.Multiple(() =>
        {
            Assert.That(success, Is.True);
            Assert.That(result, Is.EqualTo(expected));
        });
    }

    [TestCase("1,2,")]
    [TestCase("1, 2,\n")]
    [TestCase("1,2\n")]
    public void GivenAStringInputWithASeparatorAtTheEnd_ThenReturnsFalse(string input)
    {
        var success = SimpleCalculator.Add(input, out var result);
        Assert.That(success, Is.False);
    }

    [TestCase("//;\n1;2", 3)]
    [TestCase("//\n\n1\n2", 3)]
    public void GivenAStringInputWithCustomSeparator_ThenItReturnsTheSum(string input, int expected)
    {
        var success = SimpleCalculator.Add(input, out var result);
        Assert.Multiple(() =>
        {
            Assert.That(success, Is.True);
            Assert.That(result, Is.EqualTo(expected));
        });
    }
}

And the code implementation:

namespace TDDKata;

public class SimpleCalculatorInput(IEnumerable<int> numbers)
{
    public bool IsValid { get; private set; } = true;
    public IEnumerable<int> Numbers { get; private set; } = numbers;

    private static readonly char[] _DefaultSeparators = [',', '\n'];

    public static SimpleCalculatorInput Create(string input)
    {
        if (input.Length == 0)
        {
            var emptyResult = new SimpleCalculatorInput(numbers: [])
            {
                IsValid = true
            };
            return emptyResult;
        }

        ParseCustomSeparator(input, out string calculationInput, out char[] separators);

        if (!IsInputStringValid(input, separators))
        {
            var invalidResult = new SimpleCalculatorInput(numbers: [])
            {
                IsValid = false
            };
            return invalidResult;
        }

        bool success = GetNumbers(calculationInput, separators, out var numbers);
        var result = new SimpleCalculatorInput(numbers)
        {
            IsValid = success
        };
        return result;
    }

    public static implicit operator SimpleCalculatorInput(string input)
    {
        return Create(input);
    }

    private static bool IsInputStringValid(string input, char[] separators)
    {
        var lastChar = input.Last();
        return !separators.Contains(lastChar);
    }

    private static void ParseCustomSeparator(string input, out string calculationInput, out char[] separators)
    {
        bool hasCustomSeparator =
            input.Length > 4 && input[0] == '/' && input[1] == '/' && input[3] == '\n';

        if (!hasCustomSeparator)
        {
            separators = _DefaultSeparators;
            calculationInput = input;
            return;
        }
        separators = [.._DefaultSeparators, input[2]];
        calculationInput = input[4..];
    }

    private static bool GetNumbers(string input, char[] separators, out IEnumerable<int> numbers)
    {
        var maybeParsedNumbers = input
            .Split(separators)
            .Select(x => x.Trim())
            .Where(static n => !string.IsNullOrWhiteSpace(n))
            .Select(static number => int.TryParse(number.Trim(), out var result) ? (int?)result : null);

        if (maybeParsedNumbers.Any(static n => n == null))
        {
            numbers = [];
            return false;
        }

        numbers = maybeParsedNumbers.Select(n => n.GetValueOrDefault());
        return true;
    }
}

public class SimpleCalculator
{
    public static bool Add(SimpleCalculatorInput input, out int result)
    {
        if (!input.IsValid)
        {
            result = 0;
            return false;
        }

        result = input.Numbers.Sum();

        return true;
    }
}

And with this we have completed our implementation of Kata 2!

Continuous Delivery and TDD Series

Juan Blasco — Tue, 28 Jan 2025 19:27:25 +0000

This series aims to introduce Test-Driven Development (TDD) to Unity C# developers and serve as a practice exercise for myself in working with TDD.

First, I strongly recommend exploring the work of Dave Farley, whose teachings and techniques have greatly influenced this series. His YouTube channel, Continuous Delivery, is an excellent resource for learning TDD concepts and their practical applications.

https://www.youtube.com/@ContinuousDelivery

One effective way to understand TDD is by practicing with programming katas. These simple problems help us focus on the TDD workflow rather than the problem itself.

https://tddmanifesto.com/exercises/

In this first post, we’ll set up a quick environment for practicing katas in C#. Let’s get started!

Simple and quick setup for C# with NUnit

This approach sets up a testing environment for katas without requiring a Unity project.

Create a solution:

dotnet new sln -n TDDKata

Create the main project and add it to the solution:

dotnet new classlib -n TDDKata
dotnet sln add TDDKata/TDDKata.csproj

Create a test project, add it to the solution, and link the main project:

dotnet new nunit -n TDDKata.Tests
dotnet sln add TDDKata.Tests/TDDKata.Tests.csproj
dotnet add TDDKata.Tests/TDDKata.Tests.csproj reference TDDKata/TDDKata.csproj

(Optional) Create a console project, add it to the solution,and link the main project:

dotnet new console -n TDDKata.Console
dotnet sln add TDDKata.Console/TDDKata.Console.csproj
dotnet add TDDKata.Console/TDDKata.Console.csproj reference TDDKata/TDDKata.csproj

Running the Tests

The test can be run with:

dotnet test

Build the project:

dotnet build

Run the console project:

dotnet run --project TDDKata.Console

TDD cycle

The TDD cycle involves three steps:

1 — Write a Test

Writing the test is often the hardest part, but it provides valuable insights. For example:

If a test is difficult to write, the code may be too coupled or doing too much.
If a test isn’t meaningful, the code may lack purpose.

2 — Implement a Minimal Solution

Write the simplest implementation to make the test pass. Modern AI tools can often assist with this step.

3 — Refactor the Code

Refactor for quality by following principles like SOLID :

S ingle Responsibility
O pen/Closed
L iskov Substitution
I nterface Segregation
D ependency Inversion

This step ensures the code is maintainable, performant, and secure.

Kata 1 — FizzBuzz

Now that we have a simple setup, let’s begin with the first kata. The initial requirement is:

Requirement 1: Write a “FizzBuzz” method that accepts a number as input and returns it as a string.

Let’s assume no other requirements exist for now and focus on writing a test for this case:

[TestCase(1, "1")]
[TestCase(-1, "-1")]
public void GivenNumber_ReturnsStringVersion(int given, string expected)
{
    string result = Kata1.FizzBuzz(given);
    Assert.That(result, Is.EqualTo(expected));
}

With a failing test in place, the next step is to fix it:

class TDDKata1 {
    public static string FizzBuzzSimple(int number) {
        return $"{number}";
    }
}

Once the test passes, we can consider refactoring. Refactoring is a critical step that can take various forms, depending on the project’s goals. In this series, we’ll evaluate our code against the SOLID principles:

S: Single Responsibility Principle — Does the code handle a single responsibility?
O: Open/Closed Principle — Is the code open for extension but closed for modification?
L: Liskov Substitution Principle — Can derived classes substitute their base class while respecting its intent?
I: Interface Segregation Principle — Should we split large contracts into more specific ones?
D: Dependency Inversion Principle — Do high-level modules depend on abstractions rather than low-level details? At this stage, there isn’t much to refactor since the requirements are minimal, and the code is straightforward.

Now we receive a new requirment:

Requirement 2 — For multiples of three return “Fizz” instead of the number

Great! First, let’s write a test to describe this new requirement:

[TestCase(3, "Fizz")]
[TestCase(9, "Fizz")]
public void GivenMultipleOfThree_ThenItReturnsFizz(int given, string expected)
{
    string result = Kata1.FizzBuzz(3);
    Assert.That(result, Is.EqualTo(expected));
}

The test fails, so let’s implement it in the simplest way we can think of:

class TDDKata1 {
  public static string FizzBuzzSimple(int number) {
      if (number % 3 == 0) { 
          return "Fizz";
      }
      return $"{number}";
  }
}

The test now passes! We enter the refactor cycle again. This time, things are more interesting because we have more requirements to consider.

When reflecting on the Open/Closed Principle, one question likely comes to mind: What happens if new rules are added? Are we going to continue increasing the complexity of the FizzBuzz method? That would definitely break the principle. So, how can we solve this?

This is the perfect opportunity to brainstorm design patterns or research possible solutions. A simple and effective solution here is to implement a Strategy Pattern, allowing us to add new rules without modifying the existing code.

Our tests provide a solid foundation, enabling us to refactor confidently without breaking the current implementation.

namespace TDDKata1;

public interface IFizzBuzzStrategy
{
    bool CanHandle(int number);
    string Handle(int number);
}

public class DefaultStrategy : IFizzBuzzStrategy
{
    public bool CanHandle(int number) => true;
    public string Handle(int number) => $"{number}";
}

public class MultipleOfThreeStrategy : IFizzBuzzStrategy
{
    public bool CanHandle(int number) => number % 3 == 0;
    public string Handle(int number) => "Fizz";
}

public class Kata1
{
    private static List<IFizzBuzzStrategy> _strategies = 
    [
        new MultipleOfThreeStrategy(),
    ];

    private static IFizzBuzzStrategy DefaultStrategy = new DefaultStrategy();

    public static string FizzBuzzSimple(int number) 
    {
        return $"{number}";
    }

    public static string FizzBuzz(int number)
    {
        foreach (IFizzBuzzStrategy strategy in _strategies)
        {
            if (strategy.CanHandle(number))
            {
                return strategy.Handle(number);
            }
        }
        return DefaultStrategy.Handle(number);
    }
}

This is much more flexible! And the tests are passing, so we can move on.

*Requirement 3 — For multiples of five, return “Buzz.”

Let’s describe this with a test:

[TestCase(5, "Buzz")]
[TestCase(10, "Buzz")]
public void GivenMultipleOfFive_ThenItRetunrsBuzz(int given, string expected)
{
    string result = Kata1.FizzBuzz(given);
    Assert.That(result, Is.EqualTo(expected));
}

This is great, our previous refactor set’s us in a great position to very quickly implement this. We just need to add a new strategy

public class MultipleOfFiveStrategy : IFizzBuzzStrategy
{
    public bool CanHandle(int number) => number % 5 == 0;
    public string Handle(int number) => "Buzz";
}

Refactor time. For the moment, nothing much to add, our current setup seems to handle for the moment all possible cases.

Requirement 4 — For numbers that are multiples of both three and five, return “FizzBuzz.”

Let’s write a test for this:

[TestCase(15, "FizzBuzz")]
[TestCase(30, "FizzBuzz")]
public void GivenMultipleOfThreeAndFive_ThenItReturnsFizzBuzz(int given, string expected)
{
    string result = Kata1.FizzBuzz(given);
    Assert.That(result, Is.EqualTo(expected));
 }

Once again, our setup works perfectly. We just need to add this new strategy:

public class MultipleOfThreeAndFiveStrategy : IFizzBuzzStrategy
{
    public bool CanHandle(int number) => number % 3 == 0 && number % 5 == 0;
    public string Handle(int number) => "FizzBuzz";
}

And with that, the kata is complete. We can imagine how more complex requirements might force us to invest more time in flexible refactors, but our current structure makes it much easier to manage. It gives us confidence that added complexity will still reproduce the simpler, correct behavior from earlier stages.