Difference between revisions of "FPTest/pl"

From Lazarus wiki
Jump to navigationJump to search
m (→‎Właściwości: poprawki)
(→‎See also: tłumaczenie na j. polski)
 
(8 intermediate revisions by the same user not shown)
Line 23: Line 23:
 
* 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.).
 
* 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.).
  
== Current status ==
+
== Aktualny stan ==
* New code remains compatible with existing test suites not relying on user modified DUnit code.
+
* Nowy kod pozostaje zgodny z istniejącymi zestawami testów, które nie polegają na kodzie DUnit zmodyfikowanym przez użytkownika.
* If your FPCUnit test projects use the CheckXXX() methods and not the AssertXXX() methods, it should be quite painless to switch from FPCUnit to the FPTest testing framework.
+
* 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.
* New code remains compatible with existing test suites not relying on low level TestFramework functions (e.g. TTestResult).
+
* Nowy kod pozostaje kompatybilny z istniejącymi zestawami testów, które nie polegają na funkcjach TestFramework niskiego poziomu (np.TTestResult).
* New code introduces a Project and ProjectManager class between the GUI and TextTestRunners to assist the future introduction of threaded unit testing.
+
* Nowy kod wprowadza klasę Project i ProjectManager między GUI a TextTestRunners, aby pomóc w przyszłym wprowadzeniu wątkowych testów jednostkowych.
* SetupOnce and TeardownOnce code reduces node and name clutter where test decorators would have previously been required. ''Test Decorator in FPCUnit has same design flaws, and doesn't work as expected.''
+
* 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.''
* New Test Decoration code is easier to comprehend and extend.
+
* Nowy kod dekoracji testów jest łatwiejszy do zrozumienia i rozszerzenia.
* Execution call depth per TestCase procedure has been reduced in an effort to improve testing efficiency. (Execution path is easier to follow and so eases future code change).
+
* 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).
* Individual test procedure timing is now taken on just the test method and excludes SetUp and TearDown times. The intention being to provide higher timing accuracy for method profiling. Overall Timing still brackets all code.
+
* 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.
* All existing Check procedures are supported. Several new Check procedures have been added to complete the range available.
+
* Obsługiwane są wszystkie istniejące procedury sprawdzania. Dodano kilka nowych procedur sprawdzania, aby uzupełnić dostępny zakres.
* New unit tests have been created to verify all Check() procedures detect pass and fail conditions.
+
* Utworzono nowe testy jednostkowe, aby zweryfikować, czy wszystkie procedury Check () wykrywają warunki powodzenia i niepowodzenia.
* All tests run without memory leaks or the need to allow leaks.
+
* Wszystkie testy przebiegają bez wycieków pamięci lub konieczności zezwalania na wycieki.
* New self-test unit tests are more comprehensive including checks to ensure setup conditions are properly met before executing the required tests.
+
* Nowe testy jednostkowe autotestu są bardziej kompleksowe i obejmują sprawdzenie, czy warunki konfiguracji są prawidłowo spełnione przed wykonaniem wymaganych testów.
* A Project class now handles registration and execution of grouped TestCases (TestSuites) and TestCases.
+
* Klasa Project obsługuje teraz rejestrację i wykonywanie zgrupowanych TestCases (TestSuites) i TestCases.
* Counted Tests can now be invoked inside nested Test Decorators to provide 2 or more dimensional test data
+
* 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.
* Non Optimized empty tests still fail.
+
* Niezoptymalizowane puste testy nadal kończą się niepowodzeniem.
* Tests that don't call Check() can be globally armed to fail, i.e. from the GUI.
+
* Testy, które nie wywołują funkcji Check(), mogą zostać uzbrojone globalnie, aby zakończyć się niepowodzeniem, tj. Z poziomu interfejsu GUI.
* Similarly tests causing memory leaks can optionally be globally armed to fail.
+
* Podobnie testy powodujące wycieki pamięci mogą opcjonalnie zostać uzbrojone globalnie, aby zakończyć się niepowodzeniem.
* Individual tests can optionally override the above GUI settings. (e.g. where a third party component has a known leak)
+
* Poszczególne testy mogą opcjonalnie zastąpić powyższe ustawienia GUI. (np. w przypadku znanego wycieku z komponentu strony trzeciej)
* All tests that override GUI settings can optionally be identified after test execution by additional node colours.
+
* Wszystkie testy, które zastępują ustawienia GUI, można opcjonalnie zidentyfikować po wykonaniu testu za pomocą dodatkowych kolorów węzłów.
* A count of overridden test failures is included in the execution status display.
+
* Liczba zastąpionych niepowodzeń testów jest uwzględniana na ekranie statusu wykonania.
* Overridden tests which would otherwise have failed generate a separate warning count visible in the updated GUI and Text output
+
* 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.
* Test Method names are decoupled from the execution process, allowing post compile information to be displayed at the GUI level.
+
* Nazwy metod testowych są oddzielone od procesu wykonywania, umożliwiając wyświetlanie informacji po kompilacji na poziomie GUI.
* Added XML report generator, supplementing both GUITestRunner and TextTestRunner.
+
* Dodano generator raportów XML, uzupełniający zarówno GUITestRunner, jak i TextTestRunner.
* Added capability in both GUITestRunner and TextTestRunner to skip (Exclude) individual tests separate from Enabling/Disabling tests.
+
* Dodano możliwość w GUITestRunner i TextTestRunner, aby pomijać (wykluczać) poszczególne testy niezależnie od włączonych/wyłączonych testów.
* Tool buttons to GUITestRunner to ease control and show at runtime which soft options have been selected.
+
* Przyciski narzędzi do GUITestRunner ułatwiające sterowanie i pokazujące w czasie wykonywania, które opcje programowe zostały wybrane.
  
To facilitate early testing without completely re-developing GUITestsRunner and TextTestRunner an intermediate Proxy unit and a TTestResults replacement has been interposed between the GUI and the new TestFramework. Although the original aim was to eventually completely re-develop the GUI the "Proxy" classes are working very well and may not need further work.
+
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 ==
+
== Pobieranie kodu źródłowego ==
The source code is freely available from GitHub using the following command:
+
Kod źródłowy jest bezpłatnie dostępny z GitHub za pomocą następującego polecenia:
 
<syntaxhighlight lang="bash">
 
<syntaxhighlight lang="bash">
 
git clone git://github.com/graemeg/fptest.git
 
git clone git://github.com/graemeg/fptest.git
 
</syntaxhighlight>
 
</syntaxhighlight>
or
+
lub
 
<syntaxhighlight lang="bash">
 
<syntaxhighlight lang="bash">
 
git clone https://github.com/graemeg/fptest.git
 
git clone https://github.com/graemeg/fptest.git
 
</syntaxhighlight>
 
</syntaxhighlight>
  
If you don't have [http://git-scm.com/ Git] installed, you can always grab a source code tarball (archive) too, using the following URL.
+
Jeśli nie masz zainstalowanego [http://git-scm.com/ Git], zawsze możesz pobrać paczkę z kodem źródłowym (archiwum), używając następującego adresu URL.
  
 
  https://github.com/graemeg/fptest/tarball/master
 
  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.
+
Projekt FPTest jest w trakcie aktywnego rozwoju, więc kod i dokumentacja są stale ulepszane. Z tego powodu bardzo polecam pobieranie kodu źródłowego przez git, a nie jako archiwum.
  
== Documentation ==
+
== Dokumentacja ==
FPTest documentation can be found in the ''docs'' directory as HTML files.
+
Dokumentację FPTest można znaleźć w katalogu ''docs'' jako pliki HTML.
  
== Test Example ==
+
== Przykład użycia Test ==
Here is a console sample testing project
+
To jest przykładowy projekt testowania w konsoli
  
 
<syntaxhighlight lang=pascal>
 
<syntaxhighlight lang=pascal>
Line 85: Line 85:
  
 
begin
 
begin
  // Register all tests
+
  // Rejestrowanie wszystkich testów
 
  sample_tests.RegisterTests;
 
  sample_tests.RegisterTests;
  
Line 92: Line 92:
 
</syntaxhighlight>
 
</syntaxhighlight>
  
and the unit containing the actual tests...
+
oraz moduł zawierający rzeczywiste testy...
  
 
<syntaxhighlight lang=pascal>
 
<syntaxhighlight lang=pascal>
Line 102: Line 102:
  
 
uses
 
uses
  TestFramework;  // required for TTestCase and CheckXXX() references
+
  TestFramework;  // wymagane dla odwołania się do TTestCase i CheckXXX()
  
 
type
 
type
Line 124: Line 124:
  
  
{ here we register all our test classes }
+
{ Tutaj rejestrujemy wszystkie nasze klasy testowe }
 
procedure RegisterTests;
 
procedure RegisterTests;
 
begin
 
begin
Line 134: Line 134:
 
procedure TTestCaseFirst.TestWarning;
 
procedure TTestCaseFirst.TestWarning;
 
begin
 
begin
   // Do nothing here - should cause a Warning
+
   // Nic tu nie rób - powinno wywołać ostrzeżenie
 
end;
 
end;
  
 
procedure TTestCaseFirst.TestOne;
 
procedure TTestCaseFirst.TestOne;
 
begin
 
begin
   Check(1 + 1 = 3, 'Catastrophic arithmetic failure!');
+
   Check(1 + 1 = 3, 'Katastrofalna porażka arytmetyczna!');
 
end;
 
end;
  
 
procedure TTestCaseFirst.TestNoError;
 
procedure TTestCaseFirst.TestNoError;
 
begin
 
begin
   Check(1 + 1 = 2, 'Catastrophic arithmetic failure!');
+
   Check(1 + 1 = 2, 'Katastrofalna porażka arytmetyczna!');
 
end;
 
end;
  
Line 151: Line 151:
 
   s: string;
 
   s: string;
 
begin
 
begin
   s := 'hello';
+
   s := 'cześć';
   CheckEquals('Hello', s, 'Failed CheckEquals');
+
   CheckEquals('Cześć', s, 'Niepowodzenie CheckEquals');
 
end;
 
end;
  
Line 161: Line 161:
 
   x := 10;
 
   x := 10;
 
   y := 0;
 
   y := 0;
   Check(x / y = 0, 'Failed on 1');
+
   Check(x / y = 0, 'Niepowodzenie dla 1');
 
end;
 
end;
  
Line 167: Line 167:
 
</syntaxhighlight>
 
</syntaxhighlight>
  
== Screenshots ==
+
== Zrzuty ekranu ==
Here is a screenshot of the Text Test Runner output.
+
Oto zrzut ekranu z wyjściem narzędzia Text Test Runner.
  
[[Image:fptest_console.png|Sample output of the console Text Test Runner.]]
+
[[Image:fptest_console.png|Przykładowe dane wyjściowe konsoli Text Test Runner.]]
  
Here is a screenshot of the GUI Test Runner (using the fpGUI Toolkit) to run the tiOPF test suite.
+
To jest zrzut ekranu z GUI Test Runner (przy użyciu fpGUI Toolkit) do uruchomienia zestawu testów tiOPF.
  
[[Image:fptest_fpgui.png|A screenshot of the GUI Test Runner using the fpGUI toolkit.]]
+
[[Image:fptest_fpgui.png|Zrzut ekranu narzędzia uruchamiania testów GUI przy użyciu zestawu narzędzi fpGUI.]]
  
== How does it compare to FPCUnit? ==
+
== Jak wypada to w porównaniu do FPCUnit? ==
I ([[User:Ggeldenhuys|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.
+
Ja ([[User:Ggeldenhuys|Graeme Geldenhuys]]) przez długi czas byłem użytkownikiem FPCUnit. Współtworzyłem i pomogłem rozszerzyć projekt FPCUnit. Ale FPCUnit ma pewne wady projektowe, co sprawia, że ​​jest przydatny głównie w mniejszych projektach i mniej skomplikowanych zestawach testowych. Dekoratory testów FPCUnit, jak Setup/Teardown itp. są poważnie uszkodzone. Framework testowy FPTest rozwiązuje wszystkie te problemy, dodaje o wiele więcej funkcji, jest łatwiejszy w zarządzaniu testami i wykonuje je szybciej niż równoważne projekty FPCUnit lub DUnit.
  
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.
+
Dobra wiadomość jest taka, że ​​nie jesteś zmuszony wybierać między żadnym z frameworków testowych. Lata temu dołączyłem interfejs zgodności DUnit/FPTest do FPCUnit. Daje to łatwiejszą drogę do przejścia z FPCUnit do FPTest. Jeśli więc projektujesz swoje zestawy testów przy użyciu wywołań CheckXXX() (zamiast wywołań AssertXXX()), możesz później łatwiej przełączyć się na framework FPTest bez konieczności zmiany kodu testowego.
  
== See also ==
+
== Zobacz także ==
* [[fpcunit]] Unit testing framework supplied with FPC
+
* [[fpcunit]] Struktura testów jednostkowych dostarczana z FPC

Latest revision as of 13:41, 5 January 2021

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.

Pobieranie kodu źródłowego

Kod źródłowy jest bezpłatnie dostępny z GitHub za pomocą następującego polecenia:

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

lub

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

Jeśli nie masz zainstalowanego Git, zawsze możesz pobrać paczkę z kodem źródłowym (archiwum), używając następującego adresu URL.

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

Projekt FPTest jest w trakcie aktywnego rozwoju, więc kod i dokumentacja są stale ulepszane. Z tego powodu bardzo polecam pobieranie kodu źródłowego przez git, a nie jako archiwum.

Dokumentacja

Dokumentację FPTest można znaleźć w katalogu docs jako pliki HTML.

Przykład użycia Test

To jest przykładowy projekt testowania w konsoli

program project1;

{$mode objfpc}{$H+}

uses
 Classes,
 TextTestRunner,
 sample_tests;

begin
 // Rejestrowanie wszystkich testów
 sample_tests.RegisterTests;

 RunRegisteredTests;
end.

oraz moduł zawierający rzeczywiste testy...

unit sample_tests;

{$mode objfpc}{$H+}

interface

uses
 TestFramework;  // wymagane dla odwołania się do TTestCase i CheckXXX()

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


procedure RegisterTests;


implementation

uses
  SysUtils;


{ Tutaj rejestrujemy wszystkie nasze klasy testowe }
procedure RegisterTests;
begin
  TestFramework.RegisterTest(TTestCaseFirst.Suite);
end;

{ TTestCaseFirst }

procedure TTestCaseFirst.TestWarning;
begin
  // Nic tu nie rób - powinno wywołać ostrzeżenie
end;

procedure TTestCaseFirst.TestOne;
begin
  Check(1 + 1 = 3, 'Katastrofalna porażka arytmetyczna!');
end;

procedure TTestCaseFirst.TestNoError;
begin
  Check(1 + 1 = 2, 'Katastrofalna porażka arytmetyczna!');
end;

procedure TTestCaseFirst.TestThree;
var
  s: string;
begin
  s := 'cześć';
  CheckEquals('Cześć', s, 'Niepowodzenie CheckEquals');
end;

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

end.

Zrzuty ekranu

Oto zrzut ekranu z wyjściem narzędzia Text Test Runner.

Przykładowe dane wyjściowe konsoli Text Test Runner.

To jest zrzut ekranu z GUI Test Runner (przy użyciu fpGUI Toolkit) do uruchomienia zestawu testów tiOPF.

Zrzut ekranu narzędzia uruchamiania testów GUI przy użyciu zestawu narzędzi fpGUI.

Jak wypada to w porównaniu do FPCUnit?

Ja (Graeme Geldenhuys) przez długi czas byłem użytkownikiem FPCUnit. Współtworzyłem i pomogłem rozszerzyć projekt FPCUnit. Ale FPCUnit ma pewne wady projektowe, co sprawia, że ​​jest przydatny głównie w mniejszych projektach i mniej skomplikowanych zestawach testowych. Dekoratory testów FPCUnit, jak Setup/Teardown itp. są poważnie uszkodzone. Framework testowy FPTest rozwiązuje wszystkie te problemy, dodaje o wiele więcej funkcji, jest łatwiejszy w zarządzaniu testami i wykonuje je szybciej niż równoważne projekty FPCUnit lub DUnit.

Dobra wiadomość jest taka, że ​​nie jesteś zmuszony wybierać między żadnym z frameworków testowych. Lata temu dołączyłem interfejs zgodności DUnit/FPTest do FPCUnit. Daje to łatwiejszą drogę do przejścia z FPCUnit do FPTest. Jeśli więc projektujesz swoje zestawy testów przy użyciu wywołań CheckXXX() (zamiast wywołań AssertXXX()), możesz później łatwiej przełączyć się na framework FPTest bez konieczności zmiany kodu testowego.

Zobacz także

  • fpcunit Struktura testów jednostkowych dostarczana z FPC