Как я могу проверить функции и процедуры, поскольку они не принадлежат классам в Delphi?

Question

У меня есть несколько маленьких функций в старом модуле под названием Utils.pas.

Теперь я хотел бы провести рефакторинг некоторых из них, но я думаю, что лучше написать тест раньше.С DUnit я думаю, что это невозможно без класса.

Поэтому я хотел бы знать, как я могу проверить их перед рефакторингом?

Редактировать:

Я думал, что это невозможно, потому что я пытался добавить тестовый пример в Delphi, используя Test Case Wizard.Посмотрите на рисунок ниже, где нет никаких классов и методов, поэтому я не смогу его создать.

Answer 1

AFAICT, DUnit не требует, чтобы тестируемый код существовал как методы класса.Только сами тесты должны быть классами.

РЕДАКТИРОВАТЬ : Мастер - просто удобствоВам не нужно его использовать.

Answer 2

Вы не можете протестировать автономную функцию с помощью мастера, но это не проблема для тестирования автономной функции с помощью DUnit.

Пример

  //***** A Standalone function te be tested in a unit far, far away
  function Add(v1, v2: Integer): Integer;
  ...

  //***** A testclass to contain the testmethods calling our 
  //      standalone function     
  TTestAdd = class(TTestcase)
  published
    procedure AddingComplement_ShouldEqualZero;
    procedure AddingNegativeNumbers_ShouldBeLessThanZero
    ...
  end;

  implementation

  procedure TTestAdd.AddingComplement_ShouldEqualZero;
  begin
    // Setup, Execute & Verify
    CheckEquals(0, Utils.Add(-1, 1), 'Complement doesn''t add to zero');
  end;

  procedure TTestAdd.AddingNegativeNumbers_ShouldBeLessThanZero
  begin
    // Setup, Execute & Verify
    CheckEquals(-3, Utils.Add(-1, -2), 'Add doesn''t add');
  end;

Answer 3

Реальный код должен быть сохранен. В реальном коде есть предположения, которые плохо документированы. Реальный кодекс изменяется людьми, которые забывают или никогда не знали этих предположений. Доверяйте тестам, не доверяйте коду.

Реальный TDD позволяет создавать объект и его методы перед реализацией. Вам все равно нужна четкая модель, прежде чем вы сможете написать контрольный пример.

Итак, сгенерируйте объект (ы), добавьте методы, параметры и т. Д. Вероятно, лучше использовать UML2, затем напишите тестовые примеры для них и затем реализуйте объекты. После этого запустите профилировщик и выясните, насколько ужасен ваш код, и выполните рефакторинг.

Как общее решение, почти всегда лучше написать фабричный объект для создания экземпляров и инициализации ваших объектов. Чем ближе вы подходите к основной функциональности, тем больше это становится важным.

Написать тесты для ваших ожидаемых отказов и исключений. используйте чек, чтобы убедиться.

Наконец, напишите каждый тест и посмотрите, как он провалится, прежде чем писать код для его успешного выполнения.