angielskufrancuskihiszpański

Uruchom serwery | Ubuntu > | Fedora > |


Ulubiona usługa OnWorks

lit-3.5 - Online w chmurze

Uruchom lit-3.5 u dostawcy bezpłatnego hostingu OnWorks przez Ubuntu Online, Fedora Online, emulator online Windows lub emulator online MAC OS

To jest polecenie lit-3.5, które można uruchomić u dostawcy bezpłatnego hostingu OnWorks przy użyciu jednej z naszych wielu darmowych stacji roboczych online, takich jak Ubuntu Online, Fedora Online, emulator online Windows lub emulator online MAC OS

PROGRAM:

IMIĘ


świeci - Zintegrowany tester LLVM

STRESZCZENIE


oświetlony [Opcje] [Testy]

OPIS


oświetlony to przenośne narzędzie do wykonywania zestawów testów w stylu LLVM i Clang, podsumowujące ich
wyniki i wskazanie awarii. oświetlony ma być lekki
narzędzie testowe z tak prostym interfejsem użytkownika, jak to tylko możliwe.

oświetlony powinien być uruchamiany z jednym lub więcej Testy do uruchomienia określony w wierszu poleceń. Testy mogą
być indywidualnymi plikami testowymi lub katalogami do wyszukiwania testów (zobacz TEST ODKRYCIE).

Każdy określony test zostanie wykonany (potencjalnie równolegle) i po wykonaniu wszystkich testów
był prowadzony oświetlony wydrukuje podsumowanie informacji o liczbie testów, które zakończyły się powodzeniem lub niepowodzeniem
(Patrz TEST STATUS WYNIKI). oświetlony program wykona z niezerowym kodem wyjścia, jeśli taki istnieje
testy kończą się niepowodzeniem.

Domyślnie oświetlony użyje zwięzłego wyświetlania postępu i wydrukuje tylko podsumowanie
informacje o niepowodzeniach testów. Widzieć WYDAJNOŚĆ OPCJE dla opcji sterujących oświetlony
wyświetlanie postępu i wyjście.

oświetlony zawiera również szereg opcji do kontrolowania sposobu wykonywania testów (specyficzne
funkcje mogą zależeć od konkretnego formatu testu). Widzieć WYKONANIE OPCJE więcej
informacje.

Wreszcie, oświetlony obsługuje również dodatkowe opcje tylko do uruchamiania podzbioru opcji
określone w wierszu poleceń, zobacz WYBÓR OPCJE po więcej informacji.

Użytkownicy zainteresowani oświetlony architektura lub projektowanie a oświetlony wdrożenie testów powinno
widzieć OŚWIETLONY INFRASTRUKTURA.

GENERAŁ OPCJE


-h, --help
Pokaż oświetlony wiadomość pomocy.

-j N, --wątki=N
run N testy równolegle. Domyślnie jest to automatycznie wybierane, aby dopasować
liczba wykrytych dostępnych procesorów.

--config-prefix=NAZWA
w szukaniu IMIĘ.cfg i IMIĘ.site.cfg gdy poszukiwania dla test apartamenty, zamiast of
lit.cfg i lit.site.cfg.

--param NAZWA, --param NAZWA=WARTOŚĆ
Dodaj parametr zdefiniowany przez użytkownika IMIĘ z danym WARTOŚĆ (lub pusty ciąg, jeśli nie)
dany). Znaczenie i użycie tych parametrów zależy od zestawu testów.

WYDAJNOŚĆ OPCJE


-Q, --cichy
Pomiń wszystkie dane wyjściowe z wyjątkiem niepowodzeń testowych.

-tak, --zwięzły
Pokaż mniej danych wyjściowych, na przykład nie pokazuj informacji o testach, które przeszły pomyślnie.

-v, --gadatliwy
Pokaż więcej informacji o niepowodzeniach testów, na przykład zamiast tego cały wynik testu
tylko wyniku testu.

--brak paska postępu
Nie używaj paska postępu opartego na klątwach.

WYKONANIE OPCJE


--ścieżka=ŚCIEŻKA
Określ dodatkowe PATH do użycia podczas wyszukiwania plików wykonywalnych w testach.

--vg Uruchom poszczególne testy pod valgrindem (za pomocą narzędzia memcheck). ten
-- kod wyjścia błędu Argument za valgrindem jest używany tak, że awarie valgrinda spowodują
program do wyjścia z niezerowym statusem.

Gdy ta opcja jest włączona, oświetlony automatycznie poda także „Valgrind"
funkcja, która może być użyta do warunkowego wyłączenia (lub oczekiwania na awarię) pewnych
testów.

--vg-arg=ARG
Gdy --vg jest używany, podaj dodatkowy argument do przekazania Valgrind sama.

--vg-przeciek
Gdy --vg jest używany, włącz sprawdzanie wycieków pamięci. Gdy ta opcja jest włączona, oświetlony
automatycznie poda także „vg_leak" funkcja, której można użyć do
warunkowo wyłącz (lub spodziewaj się niepowodzenia) niektórych testów.

--testy-czasowe
Śledź czas potrzebny na wykonanie poszczególnych testów i uwzględnij wyniki w
wynik podsumowania. Jest to przydatne do określenia, które testy w zestawie testów
poświęć najwięcej czasu na wykonanie. Zauważ, że ta opcja jest najbardziej użyteczna z -j 1.

WYBÓR OPCJE


--max-testów=N
Uruchom najwyżej N testy, a następnie zakończyć.

--max-czas=N
Wydaj najwyżej N sekund (w przybliżeniu) uruchamiania testów, a następnie zakończyć.

--człapać
Uruchom testy w losowej kolejności.

DODATKOWY OPCJE


--odpluskwić
run oświetlony w trybie debugowania, do debugowania problemów z konfiguracją i oświetlony sama.

--apartamenty
Wymień wykryte zestawy testów i zakończ.

--pokaż-testy
Wypisz wszystkie wykryte testy i wyjdź.

EXIT STATUS


oświetlony zakończy działanie z kodem wyjścia 1, jeśli pojawią się jakiekolwiek wyniki FAIL lub XPASS. Inaczej,
wyjdzie ze statusem 0. Inne kody wyjścia są używane dla niepowodzeń niezwiązanych z testowaniem
(na przykład błąd użytkownika lub wewnętrzny błąd programu).

TEST ODKRYCIE


Dane wejściowe przekazane do oświetlony mogą być pojedynczymi testami lub całymi katalogami lub
hierarchie testów do uruchomienia. Kiedy oświetlony uruchamia się, pierwszą rzeczą, którą robi, jest konwersja
dane wejściowe do pełnej listy testów do uruchomienia w ramach test odkrycie.

w oświetlony model, każdy test musi istnieć wewnątrz jakiegoś test apartament. oświetlony rozwiązuje wejścia
określone w wierszu poleceń, aby przetestować pakiety, przeszukując w górę od ścieżki wejściowej
dopóki nie znajdzie lit.cfg or lit.site.cfg plik. Pliki te służą zarówno jako znacznik testu
pakiety i jako pliki konfiguracyjne, które oświetlony ładunki, aby zrozumieć, jak znaleźć i
uruchom testy wewnątrz zestawu testów.

Pewnego razu oświetlony zmapował dane wejściowe do zestawów testowych, przemierza listę dodawanych danych wejściowych
testy dla poszczególnych plików i rekurencyjne wyszukiwanie testów w katalogach.

To zachowanie ułatwia określenie podzbioru testów do uruchomienia, jednocześnie umożliwiając
konfiguracja zestawu testów, aby dokładnie kontrolować sposób interpretacji testów. Ponadto, oświetlony
zawsze identyfikuje testy według zestawu testów, w którym się znajdują, oraz ich względną ścieżkę wewnątrz
zestaw testowy. W przypadku odpowiednio skonfigurowanych projektów pozwala to: oświetlony zapewnić wygodne
i elastyczne wsparcie dla kompilacji spoza drzewa.

TEST STATUS WYNIKI


Każdy test ostatecznie daje jeden z następujących sześciu wyników:

PASS
Test się powiódł.

XBŁĄD
Test się nie powiódł, ale tego można się spodziewać. Jest to używane w przypadku formatów testowych, które pozwalają
określając, że test obecnie nie działa, ale chcesz pozostawić go w zestawie testów.

XPASS
Test się powiódł, ale spodziewano się niepowodzenia. Jest to używane do testów, które były
określone zgodnie z oczekiwaniami, aby zakończyć się niepowodzeniem, ale teraz się powiodły (ogólnie dlatego, że funkcja
test został uszkodzony i został naprawiony).

FAIL
Test się nie powiódł.

NIE ROZWIĄZANY
Nie można było ustalić wyniku testu. Na przykład dzieje się tak, gdy test może:
nie zostać uruchomiony, sam test jest nieważny lub test został przerwany.

NIEOBSŁUGIWANE
Test nie jest obsługiwany w tym środowisku. Jest to używane przez formaty testowe, które mogą:
zgłosić nieobsługiwane testy.

W zależności od formatu testu testy mogą generować dodatkowe informacje o swoim statusie
(generalnie tylko w przypadku awarii). Zobacz WYDAJNOŚĆ OPCJE sekcja po więcej informacji.

OŚWIETLONY INFRASTRUKTURA


W tej sekcji opisano oświetlony testowanie architektury dla użytkowników zainteresowanych tworzeniem nowej
oświetlony wdrożenie testowe lub rozszerzenie już istniejącej.

oświetlony właściwa jest przede wszystkim infrastrukturą do wykrywania i uruchamiania dowolnych testów oraz
aby udostępnić pojedynczy wygodny interfejs tym testom. oświetlony sam nie wie, jak biegać
testów, raczej ta logika jest zdefiniowana przez test apartamenty.

TEST APARTAMENTY
Jak opisano w TEST ODKRYCIEtesty zawsze znajdują się wewnątrz a test apartament. Zestawy testowe
służą do określenia formatu testów, które zawierają, logiki wyszukiwania tych testów,
oraz wszelkie dodatkowe informacje potrzebne do przeprowadzenia testów.

oświetlony identyfikuje zestawy testów jako katalogi zawierające lit.cfg or lit.site.cfg pliki (patrz
również --config-prefiks). Zestawy testowe są początkowo wykrywane przez rekurencyjne wyszukiwanie
hierarchia katalogów dla wszystkich plików wejściowych przekazanych w wierszu poleceń. Możesz użyć
--apartamenty aby wyświetlić wykryte zestawy testów podczas uruchamiania.

Po wykryciu zestawu testów jego plik konfiguracyjny jest ładowany. Same pliki konfiguracyjne są
Moduły Pythona, które zostaną wykonane. Kiedy plik konfiguracyjny jest wykonywany, dwa ważne
zmienne globalne są predefiniowane:

oświetlony
Globalny oświetlony obiekt konfiguracyjny (a LitConfig instancji), która definiuje wbudowane
formaty testowe, globalne parametry konfiguracyjne i inne procedury pomocnicze dla
implementacja konfiguracji testowych.

config
To jest obiekt konfiguracyjny (a Konfiguracja testowa przykład) dla zestawu testów, który
oczekuje się, że plik konfiguracyjny zostanie zapełniony. Następujące zmienne są również dostępne na
config obiekt, z których niektóre muszą być ustawione przez config, a inne są opcjonalne lub
predefiniowane:

Nazwa [wymagany] Nazwa zestawu testów do użytku w raportach i diagnostyce.

test_format [wymagany] Obiekt formatu testowego, który będzie używany do wykrywania i uruchamiania
testy w zestawie testów. Ogólnie będzie to wbudowany format testowy dostępny od
die,en lit.formaty moduł.

test_source_root Ścieżka systemu plików do katalogu głównego zestawu testów. Dla kompilacji out-of-dir
jest to katalog, który zostanie przeskanowany w poszukiwaniu testów.

test_exec_root W przypadku kompilacji poza katalogiem ścieżka do katalogu głównego zestawu testów wewnątrz obiektu
informator. Tutaj będą uruchamiane testy i umieszczane tymczasowe pliki wyjściowe.

środowisko Słownik reprezentujący środowisko do użycia podczas wykonywania testów w
apartament.

sufiksy Dla oświetlony formaty testowe, które skanują katalogi w poszukiwaniu testów, ta zmienna jest listą
przyrostków do identyfikacji plików testowych. Używany przez: ShTest.

substytucje Dla oświetlony formaty testowe, które zastępują zmienne w skrypcie testowym,
lista zastępstw do wykonania. Używany przez: ShTest.

nieobsługiwane Oznacz nieobsługiwany katalog, wszystkie znajdujące się w nim testy zostaną zgłoszone jako
nieobsługiwane. Używany przez: ShTest.

roślina mateczna Konfiguracja nadrzędna, jest to obiekt konfiguracyjny dla katalogu zawierającego
zestaw testowy lub Brak.

korzeń Konfiguracja główna. To jest najwyższy oświetlony konfiguracja w projekcie.

on_klon Konfiguracja jest w rzeczywistości sklonowana dla każdego podkatalogu w zestawie testowym, aby
zezwalaj na lokalną konfigurację na podstawie katalogu. ten on_klon można ustawić zmienną
do funkcji Pythona, która będzie wywoływana za każdym razem, gdy sklonowana zostanie konfiguracja (dla a
podkatalogu). Funkcja powinna przyjmować trzy argumenty: (1) rodzic
konfiguracja, (2) nowa konfiguracja (która on_klon funkcja będzie ogólnie
modyfikować) oraz (3) ścieżkę testową do nowego skanowanego katalogu.

awaria potoku Zwykle test z użyciem potoku powłoki kończy się niepowodzeniem, jeśli którekolwiek z poleceń w potoku
ponieść porażkę. Jeśli nie jest to pożądane, ustawienie tej zmiennej na false powoduje, że test tylko się nie powiedzie
jeśli nie powiedzie się ostatnie polecenie w potoku.

TEST ODKRYCIE
Po zlokalizowaniu zestawów testowych oświetlony rekursywnie przemierza katalog źródłowy (postępując
test_source_root) szukam testów. Kiedy oświetlony wchodzi do podkatalogu, najpierw sprawdza, czy
sprawdź, czy w tym katalogu zdefiniowano zagnieżdżony zestaw testów. Jeśli tak, ładuje ten zestaw testów
rekursywnie, w przeciwnym razie tworzy lokalną konfigurację testową dla katalogu (zobacz LOCAL
KONFIGURACJA AKTA).

Testy są identyfikowane przez zestaw testów, w którym się znajdują, oraz względną ścieżkę
wewnątrz tego apartamentu. Zauważ, że ścieżka względna może nie odnosić się do rzeczywistego pliku na dysku;
niektóre formaty testów (takie jak Test Google) zdefiniuj „testy wirtualne”, które mają ścieżkę, która
zawiera zarówno ścieżkę do rzeczywistego pliku testowego, jak i podścieżkę identyfikującą test wirtualny.

LOCAL KONFIGURACJA AKTA
Gdy oświetlony ładuje podkatalog w zestawie testów, tworzy instancję lokalnej konfiguracji testu
klonując konfigurację dla kierunku nadrzędnego --- korzeń tej konfiguracji
łańcuch zawsze będzie zestawem testowym. Po sklonowaniu konfiguracji testowej oświetlony czeki na
lit.lokalny.cfg plik w podkatalogu. Jeśli jest obecny, ten plik zostanie załadowany i może być
służy do specjalizacji konfiguracji dla każdego indywidualnego katalogu. Ten obiekt może być
służy do definiowania podkatalogów testów opcjonalnych lub do zmiany innej konfiguracji
parametry --- na przykład, aby zmienić format testu lub przyrostki identyfikujące test
akta.

TEST BIEGAĆ WYDAJNOŚĆ FORMAT
Podczas spotkania Członkom Konsorcjum zostały zaprezentowane oświetlony dane wyjściowe dla przebiegu testowego są zgodne z następującym schematem, zarówno w wersji krótkiej, jak i pełnej
tryby (chociaż w trybie skróconym nie będą wyświetlane żadne linie PASS). Ten schemat został wybrany
być stosunkowo łatwym do niezawodnego parsowania przez maszynę (na przykład w logu buildbota
skrobanie) i innych narzędzi do generowania.

Oczekuje się, że każdy wynik testu pojawi się w wierszu, który pasuje:

: ( )

gdzie to standardowy wynik testu typu PASS, FAIL, XFAIL, XPASS,
NIEROZWIĄZANE lub NIEWSPIERANE. Kody wyników wydajności ULEPSZONE i REGRESSED są
również dozwolone.

Podczas spotkania Członkom Konsorcjum zostały zaprezentowane <test imię> pole może składać się z dowolnego łańcucha nie zawierającego nowej linii.

Podczas spotkania Członkom Konsorcjum zostały zaprezentowane <progress informacje> pole może służyć do zgłaszania informacji o postępach, takich jak (1/300) lub
może być pusty, ale nawet jeśli jest pusty, nawiasy są wymagane.

Każdy wynik testu może zawierać dodatkowe (wielowierszowe) informacje dziennika w następujący sposób
format:

TEST '( )”
... komunikat dziennika ...


gdzie <test imię> powinna być nazwą poprzedniego zgłoszonego testu, <log deliniator> jest
ciąg znaków "*" at najmniej cztery znaki (zalecana długość to 20), oraz
<trailing deliniator> jest arbitralnym (nieprzeanalizowanym) ciągiem.

Poniżej znajduje się przykład wyniku przebiegu testowego, który składa się z czterech testów A, B, C i
D i komunikat dziennika dla nieudanego testu C:

PODANIE: A (1 z 4)
PODANIE: B (2 z 4)
NIEPOWODZENIE: C (3 z 4)
******************** BŁĄD TESTU „C” ********************
Test „C” nie powiódł się z powodu kodu zakończenia 1.
********************
PODANIE: D (4 z 4)

OŚWIETLONY PRZYKŁAD TESTY
Podczas spotkania Członkom Konsorcjum zostały zaprezentowane oświetlony dystrybucja zawiera kilka przykładowych implementacji zestawów testów w
Przykładowe testy katalogiem.

Korzystaj z lit-3.5 online za pomocą usług onworks.net


Ad


Ad