How can I test private methods with DUnit?

Question

I have a class that I am unit testing into with DUnit. It has a number of methods some public methods and private methods.

type
  TAuth = class(TDataModule)
  private
    procedure PrivateMethod;
  public
    procedure PublicMethod;
  end;

In order to write a unit test for this class I have to make all the methods public.

Is there a different way to declare the private methods so that I can still test them but they are not public?

Answer 1

You don't need to make them public. Protected will do. Then you can subtype the class for unit testing and surface the protected methods. Example:

type
  TAuth = class(TDataModule)
  protected
    procedure MethodIWantToUnitTest;
  public
    procedure PublicMethod;
  end;

Now you can subtype it for your unit test:

interface

uses
  TestFramework, Classes, AuthDM;

type
  // Test methods for class TAuthDM
  TestAuthDM = class(TTestCase)
     // stuff
  end;

  TAuthDMTester = class(TAuthDM)
  public
    procedure MethodIWantToUnitTestMadePublic;
  end;

implementation

procedure TAuthDMTester.MethodIWantToUnitTestMadePublic;
begin
  MethodIWantToUnitTest;
end;

However, if the methods you want to unit test are doing things so intimately with the data module that it is not safe to have them anything but private, then you should really consider refactoring the methods in order to segregate the code which needs to be unit tested and the code which accesses the innards of the data module.

Answer 2

It is a little hacky, but I think this is the simplest and clearer approach. Use this conditional compilation directive:

  {$IfNDef TEST}
  private
  {$EndIf}

Your unit test project must define TEST in project → conditional defines. Without a visibility specification, they become published.

Beware: if the private visibility isn't the first one in the class declaration, it will get the previous definition. A safer way, but more verbose and less clear, would be:

  private
  {$IfDef TEST}
  public
  {$EndIf}

This has a lot of advantages over the subclassing or other approaches:

• No extra complexity: no extra classes in your code.
• Nobody can "mistakenly" subclass and override your class: you preserve your architecture.
• When you say a method is protected, you somewhat expect that it will be overridden. You are telling this for who is reading your code. A protected method that shouldn't be overridden will confuse your code readers, breaking my first programming principle: "Code must be written to be read by other human beings."
• DUnit is in their own unit, not included everywhere.
• You don't touch messy RTTI.

I think it is a clearer solution, and better than the selected answer.

When I use this, I also configure the test project to put the build objects in a different directory of the main project. This prevents the binaries with the TEST directive to mix with the other code.