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?

See also: [What's the proper way to test a class with private methods using JUnit?](http://stackoverflow.com/questions/34571/whats-the-proper-way-to-test-a-class-with-private-methods-using-junit) — mjn, Nov 15 '12 at 12:24
Another option http://stackoverflow.com/questions/7525071/accesing-a-strict-private-field-using-the-rtti — sav, Dec 11 '14 at 02:21
Possible duplicate of [How do I test a class that has private methods, fields or inner classes?](https://stackoverflow.com/questions/34571/how-do-i-test-a-class-that-has-private-methods-fields-or-inner-classes) — Raedwald, Dec 14 '17 at 13:08

Craig Stuntz · Accepted Answer · 2009-01-07T22:30:27.170

21

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.

edited Jan 07 '09 at 22:30

answered Jan 07 '09 at 22:16

Craig Stuntz

125,891
12
252
273

3

Yeah without sounding too negative I don't agree with making your private methods protected for the sake of unit testing as they are private for a reason. I think you should be testing the public interface. It's the public methods which are going to be using your private methods anyway. – CodeAndCats Jan 13 '09 at 00:50
1

I (respectfully) disagree, for reasons I elaborate here: http://blogs.teamb.com/craigstuntz/2009/01/12/37919/ – Craig Stuntz Jan 13 '09 at 01:27
1

/Ben: private and protected are different isibilities and each has it's merits and disadvantages; If you want to e able to test the private methods, making those protected is simply a crude way of making them accessible to your testing framework (DUnit). What's next: private is evil, and strict private even more? I agree with Ben: unit testing is for testing your contract (eg the public interface with it's explicit (interface) and explicit (usage) rules). If the private members need testing, you should make that interface formal (part of an interface perhaps, inner class etc). – Ritsaert Hornstra Mar 15 '10 at 00:51
2

Unit testing provides a harness which gives you coverage. In this case, TDD religion is conflicting with OOP religion. Expect holy wars to ensue. – Warren P Sep 02 '12 at 21:01

neves · Answer 2 · 2019-07-04T18:15:50.247

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.

score 5 · Answer 3 · answered Mar 13 '10 at 09:50

I recommend the "XUnit Test Patterns" book by Gerard Meszaros:

Test-Specific Subclass

Question: How can we make code testable when we need to access private state of the SUT?

Answer: Add methods that expose the state or behavior needed by the test to a subclass of the SUT.

... If the system under test (SUT) was not designed specifically to be testable, we may find that the test cannot get access to state that it must initialize or verify at some point in the test.

The article also explains when to use it and which risks it carries.

score 4 · Answer 4 · answered Mar 15 '10 at 00:29

4

Put the DUnit code within your unit. You can then access anything you like.

answered Mar 15 '10 at 00:29

Brian Frost

13,334
11
80
154

3

... by using conditional directives only – too Jun 25 '10 at 10:45

score 4 · Answer 5 · answered Feb 07 '12 at 12:03

In general, when I get in this situation, I often realize that I'm violating the single responsibility principle. Of course I know nothing about your specific case, but MAYBE, that private methods should be in their own class. The TAuth would than have a reference to this new class in it's private section.

score 2 · Answer 6 · edited May 23 '17 at 12:26

2

With Extended RTTI (Delphi 2010 and newer), invoking private methods via RTTI is another option. This solution is also the top-rated answer in How do I test a class that has private methods, fields or inner classes?

edited May 23 '17 at 12:26

Community

1
1

answered Nov 15 '12 at 12:34

mjn

36,362
28
176
378

score 2 · Answer 7 · answered Aug 24 '14 at 17:36

2

{$IFNDEF UNITEST}
private
{$ENDIF}

Simple solution, which hardly is a hack. I frequently need to test private methods and this technique adds as little complication as possible.

answered Aug 24 '14 at 17:36

Mads Boyd-Madsen

145
1
2

How can I test private methods with DUnit?

7 Answers7

Linked