FPTest/pl

From Lazarus wiki
Revision as of 13:41, 5 January 2021 by Slawek (talk | contribs) (See also: tłumaczenie na j. polski)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

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