Test-Driven Development (TDD) in Delphi with DUnitX

This skill guides behavioral expectations for test-driven development (TDD) using the modern Delphi ecosystem.

When operating under the scope of TDD, AI MUST ALWAYS prioritize the Red-Green-Refactor cycle. If the user requests TDD, DO NOT write the business implementation before writing the test that will fail.

The Red-Green-Refactor Cycle (Interaction Rules)

1. Red (Failed Test): Start by declaring the skeleton of the target class/interface in the

   interface

   section just to compile. Then, immediately write a complete DUnitX Test Case calling out the non-existent behavior or asserting an expected result. The test will logically fail.
2. Green (Minimal Code): Write the minimum and raw actual implementation, enough to make the test

   Assert

   pass.
3. Refactor (Cleaning): Improve the code (Clean Code, duplication removal, optimizations) ensuring that the test does not break.

DUnitX Best Practices

Test Structure

• Test Class: The test case must be annotated with

  [TestFixture]

  .
• Setup and TearDown: Use

  [Setup]

  to instantiate Classes and Fakes. Use

  [TearDown]

  to clean up instances that do not use ARC (Interfaces).
• No Memory Leaks in Tests:

  [TearDown]

  and injection via Interface (ARC) are mandatory to keep the suite watertight.

Nomenclature of Test Methods

Embrace context conventions like Action_Condition_ExpectedResult:

[Test]
procedure ComputeDiscount_LoyalCustomer_ReturnsTenPercent;

Modern Assertions

Replace manual Boolean validations (

Assert.IsTrue(A = B)

) with fluent and specific

Assert

:

• Assert.AreEqual(100.0, FInvoice.Total)

• Assert.IsNotNull(FCustomer)

• Assert.WillRaise(procedure begin FSut.DoInvalid; end, EBusinessRuleException)

• Assert.Contains('Error', LMessage)

Dependency Injection and Mocks (Test Doubles)

To isolate the class under test (SUT - System Under Test) from the infrastructure (Database, APIs, View), apply Strict Dependency Inversion (DIP) by injecting

Interfaces

into the SUT via constructor.

As Delphi does not have a built-in Mocking Framework in RTL, write local "Fake/Mock" Classes implementing the Interface to simulate the dependency within the test's

implementation

session.

//Fake is created only in the test file
TFakeEmailService = class(TInterfacedObject, IEmailService)
public
  SentCount: Integer;
  procedure Send(const AMsg: string);
end;

AntiPatterns that AI should Avoid

1. ❌ Direct coupling to the database (

   TFDQuery

   ) in the tested class. Always abstract database access into a

   IRepository

   and create a

   TFakeRepository

   for DUnitX.
2. ❌ Test UI. Restrict the scope of DUnitX to the Domain and Application Services Layer.
3. ❌ Write the entire class along with the tests. The user must be followed step-by-step in TDD. If the AI ​​is required to provide everything, send the Tests first in the output.
4. ❌ Swallowing Exceptions (

   try..except on E: Exception do

   ) in methods being tested, this breaks

   Assert.WillRaise()

   .