Вы не должны обнародовать их. Защищенный сделает. Затем можно выделить подтипы в классе для поблочного тестирования и появиться защищенные методы. Пример:
type
TAuth = class(TDataModule)
protected
procedure MethodIWantToUnitTest;
public
procedure PublicMethod;
end;
Теперь можно выделить подтипы в нем для модульного теста:
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;
Однако, если методы Вы хотите к модульному тесту, делают вещи так глубоко с модулем данных, что не безопасно иметь их почти частный, затем необходимо действительно рассмотреть рефакторинг методов для разделения кода, который должен быть протестированной единицей и код, который получает доступ к внутренностям модуля данных.
Поместите код DUnit в свой модуль. Затем вы можете получить доступ ко всему, что захотите.
Я рекомендую книгу « XUnit Test Patterns » автора Жерар Месарос:
Подкласс, специфичный для теста
Вопрос : Как мы можем сделать код тестируемым, когда нам нужно получить доступ к частному состоянию SUT?
Ответ : добавьте методы, которые раскрывают состояние или поведение , необходимое для теста , в подкласс SUT.
... Если тестируемая система (SUT) не была разработана специально для тестирования, мы можем обнаружить, что тест не может получить доступ, чтобы указать, что он должен инициализироваться или проверяться на каком-то этапе теста.
В статье также объясняется, когда его использовать и какие риски он несет.