FPTest/pl

│ English (en) │ français (fr) │ polski (pl) │

FPTest (Free Pascal Testing Framework) to framework do testów jednostkowych. Jest to rozwidlenie projektu DUnit2 stworzonego przez zmarłego Petera McNaba, ale poprawione specjalnie do użytku z kompilatorem Free Pascal.

Wiele z poniższych pozycji odnosi się do oryginalnego projektu DUnit2 (a teraz projektu FPTest) i tego, jak różni się on od projektu Delphi DUnit. Przedstawiono również informacje o migracji z fpcunit.

Właściwości

Cele projektowe stosowane podczas opracowywania projektu, niekoniecznie w określonej kolejności:

• Wprowadzenie do SetUpOnce i TearDownOnce dla TestCase i TestSuite.
• Poprawienie szybkość wykonywania testu.
• Wprowadzenie do wielu "projektów" i otwórzenie drogi do uruchamiania testów projektów w osobnych wątkach.
• Poprawienie łatwości korzystania z FPTest (częściowo poprzez dodanie więcej przykładowej dokumentacji).
• Upewnienie się, że TTestCase Constructors i Destructors wykonują się tylko raz, a nie dla każdej zawartej metody testowej.
• Zapewnienie nieglobalnych środków do udostępniania danych konfiguracji wysokiego poziomu między jednostkami testowymi.
• Bardziej dokładne wyniki testów i ulepszone informacje zwrotne.
• Zapewnienie wizualnej liczby wykrytych wycieków pamięci i testów bez funkcji Check().
• Zapewnia opcjonalną liczbę określającą, które wywołania funkcji Check() zakończyły się niepowodzeniem.
• Czyszczenie kodu poprzez usunięcie starszego kodu w FPTest, takiego jak Delphi Win32 i specyficzny kod .Net.
• Text Test Runner dla tych, którzy lubią konsole lub dla nienadzorowanych pakietów testów działających na serwerach.
• Nowy GUI Test Runner do fpGUI lub projektów opartych na LCL.
• Znacznie bardziej zaawansowany Test Decorator, który faktycznie działa (FPCUnit jest całkowicie zepsuty).
• Zarejestrowane testy można teraz organizować znacznie lepiej, budując hierarchię testów, ułatwiając zarządzanie (włączanie, wyłączanie, pomijanie testów itp.).

Aktualny stan

• Nowy kod pozostaje zgodny z istniejącymi zestawami testów, które nie polegają na kodzie DUnit zmodyfikowanym przez użytkownika.
• Jeśli projekty testowe FPCUnit używają metod CheckXXX(), a nie metod AssertXXX(), przejście z FPCUnit do frameworka testowego FPTest powinno być dość bezbolesne.
• Nowy kod pozostaje kompatybilny z istniejącymi zestawami testów, które nie polegają na funkcjach TestFramework niskiego poziomu (np.TTestResult).
• Nowy kod wprowadza klasę Project i ProjectManager między GUI a TextTestRunners, aby pomóc w przyszłym wprowadzeniu wątkowych testów jednostkowych.
• Kod SetupOnce i TeardownOnce redukuje bałagan w węzłach i nazwach, w których wcześniej wymagane były dekoratory testów. Dekorator testów w FPCUnit ma te same wady projektowe i nie działa zgodnie z oczekiwaniami.
• Nowy kod dekoracji testów jest łatwiejszy do zrozumienia i rozszerzenia.
• Głębokość wywołań wykonania na procedurę TestCase została zmniejszona w celu poprawy wydajności testowania. (Ścieżka wykonania jest łatwiejsza do naśladowania, co ułatwia przyszłą zmianę kodu).
• Indywidualny czas procedury testowej jest teraz brany pod uwagę tylko dla metody testowej i nie obejmuje czasów SetUp i TearDown. Celem jest zapewnienie wyższej dokładności czasowej dla profilowania metod. Ogólny czas nadal obejmuje cały kod w nawiasach.
• Obsługiwane są wszystkie istniejące procedury sprawdzania. Dodano kilka nowych procedur sprawdzania, aby uzupełnić dostępny zakres.
• Utworzono nowe testy jednostkowe, aby zweryfikować, czy wszystkie procedury Check () wykrywają warunki powodzenia i niepowodzenia.
• Wszystkie testy przebiegają bez wycieków pamięci lub konieczności zezwalania na wycieki.
• Nowe testy jednostkowe autotestu są bardziej kompleksowe i obejmują sprawdzenie, czy warunki konfiguracji są prawidłowo spełnione przed wykonaniem wymaganych testów.
• Klasa Project obsługuje teraz rejestrację i wykonywanie zgrupowanych TestCases (TestSuites) i TestCases.
• Zliczanie testów można teraz wywoływać wewnątrz zagnieżdżonych dekoratorów testów, aby zapewnić 2 lub więcej danych wymiarowych.
• Niezoptymalizowane puste testy nadal kończą się niepowodzeniem.
• Testy, które nie wywołują funkcji Check(), mogą zostać uzbrojone globalnie, aby zakończyć się niepowodzeniem, tj. Z poziomu interfejsu GUI.
• Podobnie testy powodujące wycieki pamięci mogą opcjonalnie zostać uzbrojone globalnie, aby zakończyć się niepowodzeniem.
• Poszczególne testy mogą opcjonalnie zastąpić powyższe ustawienia GUI. (np. w przypadku znanego wycieku z komponentu strony trzeciej)
• Wszystkie testy, które zastępują ustawienia GUI, można opcjonalnie zidentyfikować po wykonaniu testu za pomocą dodatkowych kolorów węzłów.
• Liczba zastąpionych niepowodzeń testów jest uwzględniana na ekranie statusu wykonania.
• Przesłonięte testy (overridden), które w innym przypadku zakończyłyby się niepowodzeniem, generują osobną liczbę ostrzeżeń widoczną w zaktualizowanym interfejsie GUI i wynikach tekstowych.
• Nazwy metod testowych są oddzielone od procesu wykonywania, umożliwiając wyświetlanie informacji po kompilacji na poziomie GUI.
• Dodano generator raportów XML, uzupełniający zarówno GUITestRunner, jak i TextTestRunner.
• Dodano możliwość w GUITestRunner i TextTestRunner, aby pomijać (wykluczać) poszczególne testy niezależnie od włączonych/wyłączonych testów.
• Przyciski narzędzi do GUITestRunner ułatwiające sterowanie i pokazujące w czasie wykonywania, które opcje programowe zostały wybrane.

Aby ułatwić wczesne testowanie bez całkowitego ponownego opracowywania GUITestsRunner i TextTestRunner, pośredni moduł Proxy i zamiennik TTestResults zostały wstawione między GUI a nową TestFramework. Chociaż pierwotnym celem było całkowite przeprojektowanie GUI, klasy „Proxy” działają bardzo dobrze i mogą nie wymagać dalszej pracy.

Get the source code

The source code is freely available from GitHub using the following command:

git clone git://github.com/graemeg/fptest.git

or

git clone https://github.com/graemeg/fptest.git

If you don't have Git installed, you can always grab a source code tarball (archive) too, using the following URL.

https://github.com/graemeg/fptest/tarball/master

The FPTest project is under active development, so code and documentation are constantly improved. For this reason I highly recommend you get the source code via git, instead of as a tarball.

Documentation

FPTest documentation can be found in the docs directory as HTML files.

Test Example

Here is a console sample testing project

program project1;

{$mode objfpc}{$H+}

uses
 Classes,
 TextTestRunner,
 sample_tests;

begin
 // Register all tests
 sample_tests.RegisterTests;

 RunRegisteredTests;
end.

and the unit containing the actual tests...

unit sample_tests;

{$mode objfpc}{$H+}

interface

uses
 TestFramework;  // required for TTestCase and CheckXXX() references

type
 TTestCaseFirst = class(TTestCase)
 published
   procedure TestWarning;
   procedure TestOne;
   procedure TestNoError;
   procedure TestThree;
   procedure TestFour;
 end;


procedure RegisterTests;


implementation

uses
  SysUtils;


{ here we register all our test classes }
procedure RegisterTests;
begin
  TestFramework.RegisterTest(TTestCaseFirst.Suite);
end;

{ TTestCaseFirst }

procedure TTestCaseFirst.TestWarning;
begin
  // Do nothing here - should cause a Warning
end;

procedure TTestCaseFirst.TestOne;
begin
  Check(1 + 1 = 3, 'Catastrophic arithmetic failure!');
end;

procedure TTestCaseFirst.TestNoError;
begin
  Check(1 + 1 = 2, 'Catastrophic arithmetic failure!');
end;

procedure TTestCaseFirst.TestThree;
var
  s: string;
begin
  s := 'hello';
  CheckEquals('Hello', s, 'Failed CheckEquals');
end;

procedure TTestCaseFirst.TestFour;
var
  x, y: integer;
begin
  x := 10;
  y := 0;
  Check(x / y = 0, 'Failed on 1');
end;

end.

Screenshots

Here is a screenshot of the Text Test Runner output.

Here is a screenshot of the GUI Test Runner (using the fpGUI Toolkit) to run the tiOPF test suite.

How does it compare to FPCUnit?

I (Graeme Geldenhuys) was a long time FPCUnit user. I contributed towards, and helped extend the FPCUnit project. But FPCUnit has some design flaws which makes it mostly useful for smaller projects and less complicated test suites. FPCUnit's test decorators, Setup/Teardown etc is severely broken. The FPTest testing framework overcomes all those issues, adds many more features, is easier to manage your tests, and executes faster that FPCUnit or DUnit equivalent projects.

The good news is that you are not forced to choose between either testing framework. Years ago I included a DUnit/FPTest compatibility interface to FPCUnit. This gives you a nice upgrade path from FPCUnit to FPTest. So if you design your test suites using the CheckXXX() calls (instead of the AssertXXX() calls), later you can easily switch to the FPTest framework without any need for changing your testing code.

See also

• fpcunit Unit testing framework supplied with FPC