Unit Testing

Base.runtests(tests=["all"]; ncores=ceil(Int, Sys.CPU_THREADS / 2),
              exit_on_error=false, revise=false, [seed])

Führen Sie die in tests aufgeführten Julia-Einheitstests aus, die entweder eine Zeichenfolge oder ein Array von Zeichenfolgen sein können, unter Verwendung von ncores Prozessoren. Wenn exit_on_error auf false gesetzt ist, werden bei einem fehlgeschlagenen Test alle verbleibenden Tests in anderen Dateien weiterhin ausgeführt; andernfalls werden sie verworfen, wenn exit_on_error == true. Wenn revise auf true gesetzt ist, wird das Revise-Paket verwendet, um alle Änderungen an Base oder an den Standardbibliotheken vor der Ausführung der Tests zu laden. Wenn ein Seed über das Schlüsselwort-Argument bereitgestellt wird, wird er verwendet, um den globalen RNG im Kontext, in dem die Tests ausgeführt werden, zu initialisieren; andernfalls wird der Seed zufällig gewählt.

@test ex
@test f(args...) key=val ...
@test ex broken=true
@test ex skip=true

Testen Sie, ob der Ausdruck ex zu true evaluiert. Wenn er innerhalb eines @testset ausgeführt wird, geben Sie ein Pass Result zurück, wenn dies der Fall ist, ein Fail Result, wenn es false ist, und ein Error Result, wenn es nicht evaluiert werden konnte. Wenn es außerhalb eines @testset ausgeführt wird, werfen Sie stattdessen eine Ausnahme, anstatt Fail oder Error zurückzugeben.

Beispiele

julia> @test true
Test Bestanden

julia> @test [1, 2] + [2, 1] == [3, 3]
Test Bestanden

Die Form @test f(args...) key=val... ist äquivalent zu @test f(args..., key=val...), was nützlich sein kann, wenn der Ausdruck ein Aufruf mit Infix-Syntax ist, wie z. B. ungefähre Vergleiche:

julia> @test π ≈ 3.14 atol=0.01
Test Bestanden

Dies ist äquivalent zu dem unansehnlicheren Test @test ≈(π, 3.14, atol=0.01). Es ist ein Fehler, mehr als einen Ausdruck anzugeben, es sei denn, der erste ist ein Aufrufausdruck und der Rest sind Zuweisungen (k=v).

Sie können jeden Schlüssel für die key=val Argumente verwenden, außer für broken und skip, die im Kontext von @test spezielle Bedeutungen haben:

• broken=cond zeigt einen Test an, der bestehen sollte, aber derzeit konsequent fehlschlägt, wenn cond==true. Tests, dass der Ausdruck ex zu false evaluiert oder eine Ausnahme verursacht. Gibt ein Broken Result zurück, wenn dies der Fall ist, oder ein Error Result, wenn der Ausdruck zu true evaluiert. Der reguläre @test ex wird evaluiert, wenn cond==false.
• skip=cond kennzeichnet einen Test, der nicht ausgeführt werden sollte, aber in der Testzusammenfassungsberichterstattung als Broken enthalten sein sollte, wenn cond==true. Dies kann nützlich sein für Tests, die intermittierend fehlschlagen, oder Tests von noch nicht implementierten Funktionen. Der reguläre @test ex wird evaluiert, wenn cond==false.

Beispiele

julia> @test 2 + 2 ≈ 6 atol=1 broken=true
Test Broken
  Ausdruck: ≈(2 + 2, 6, atol = 1)

julia> @test 2 + 2 ≈ 5 atol=1 broken=false
Test Bestanden

julia> @test 2 + 2 == 5 skip=true
Test Broken
  Übersprungen: 2 + 2 == 5

julia> @test 2 + 2 == 4 skip=false
Test Bestanden

@test_throws exception expr

Testet, dass der Ausdruck expr exception auslöst. Die Ausnahme kann entweder einen Typ, einen String, einen regulären Ausdruck oder eine Liste von Strings, die in der angezeigten Fehlermeldung vorkommen, eine Übereinstimmungsfunktion oder einen Wert angeben (der auf Gleichheit durch den Vergleich von Feldern getestet wird). Beachten Sie, dass @test_throws keine abschließende Schlüsselwortform unterstützt.

Beispiele

julia> @test_throws BoundsError [1, 2, 3][4]
Test bestanden
      Ausgelöst: BoundsError

julia> @test_throws DimensionMismatch [1, 2, 3] + [1, 2]
Test bestanden
      Ausgelöst: DimensionMismatch

julia> @test_throws "Versuchen Sie sqrt(Complex" sqrt(-1)
Test bestanden
     Nachricht: "DomainError mit -1.0:\nsqrt wurde mit einem negativen reellen Argument aufgerufen, gibt jedoch nur ein komplexes Ergebnis zurück, wenn es mit einem komplexen Argument aufgerufen wird. Versuchen Sie sqrt(Complex(x))."

Im letzten Beispiel hätte anstelle der Übereinstimmung mit einem einzelnen String alternativ auch Folgendes verwendet werden können:

• ["Versuchen", "Complex"] (eine Liste von Strings)
• r"Versuchen sqrt\([Cc]omplex" (ein regulärer Ausdruck)
• str -> occursin("complex", str) (eine Übereinstimmungsfunktion)

@testset [CustomTestSet] [options...] ["Beschreibung"] begin test_ex end
@testset [CustomTestSet] [options...] ["Beschreibung $v"] for v in itr test_ex end
@testset [CustomTestSet] [options...] ["Beschreibung $v, $w"] for v in itrv, w in itrw test_ex end
@testset [CustomTestSet] [options...] ["Beschreibung"] test_func()
@testset let v = v, w = w; test_ex; end

Mit begin/end oder Funktionsaufruf

Wenn @testset verwendet wird, mit begin/end oder einem einzelnen Funktionsaufruf, startet das Makro ein neues Testset, in dem der gegebene Ausdruck ausgewertet wird.

Wenn kein benutzerdefinierter Testset-Typ angegeben ist, wird standardmäßig ein DefaultTestSet erstellt. DefaultTestSet zeichnet alle Ergebnisse auf und wirft, falls es Fails oder Errors gibt, am Ende des obersten (nicht geschachtelten) Testsets eine Ausnahme, zusammen mit einer Zusammenfassung der Testergebnisse.

Jeder benutzerdefinierte Testset-Typ (Untertyp von AbstractTestSet) kann angegeben werden und wird auch für alle geschachtelten @testset-Aufrufe verwendet. Die angegebenen Optionen werden nur auf das Testset angewendet, in dem sie angegeben sind. Der Standard-Testset-Typ akzeptiert drei boolesche Optionen:

• verbose: wenn true, wird die Ergebnisszusammenfassung der geschachtelten Testsets angezeigt, selbst wenn sie alle bestehen (der Standardwert ist false).
• showtiming: wenn true, wird die Dauer jedes angezeigten Testsets angezeigt (der Standardwert ist true).
• failfast: wenn true, führt jeder Testfehler oder Fehler dazu, dass das Testset und alle untergeordneten Testsets sofort zurückgegeben werden (der Standardwert ist false). Dies kann auch global über die Umgebungsvariable JULIA_TEST_FAILFAST festgelegt werden.

Der Beschreibungsstring akzeptiert Interpolation von den Schleifenindizes. Wenn keine Beschreibung angegeben ist, wird eine basierend auf den Variablen erstellt. Wenn ein Funktionsaufruf angegeben ist, wird dessen Name verwendet. Explizite Beschreibungsstrings überschreiben dieses Verhalten.

Standardmäßig gibt das @testset-Makro das Testset-Objekt selbst zurück, obwohl dieses Verhalten in anderen Testset-Typen angepasst werden kann. Wenn eine for-Schleife verwendet wird, sammelt und gibt das Makro eine Liste der Rückgabewerte der finish-Methode zurück, die standardmäßig eine Liste der in jeder Iteration verwendeten Testset-Objekte zurückgibt.

Vor der Ausführung des Körpers eines @testset erfolgt ein impliziter Aufruf von Random.seed!(seed), wobei seed der aktuelle Seed des globalen RNG ist. Darüber hinaus wird nach der Ausführung des Körpers der Zustand des globalen RNG auf den Zustand vor dem @testset zurückgesetzt. Dies soll die Reproduzierbarkeit im Falle eines Fehlers erleichtern und nahtlose Umstellungen von @testsets unabhängig von ihren Nebenwirkungen auf den Zustand des globalen RNG ermöglichen.

Beispiele

julia> @testset "trigonometric identities" begin
           θ = 2/3*π
           @test sin(-θ) ≈ -sin(θ)
           @test cos(-θ) ≈ cos(θ)
           @test sin(2θ) ≈ 2*sin(θ)*cos(θ)
           @test cos(2θ) ≈ cos(θ)^2 - sin(θ)^2
       end;
Test Summary:            | Pass  Total  Time
trigonometric identities |    4      4  0.2s

@testset for

Wenn @testset for verwendet wird, startet das Makro einen neuen Test für jede Iteration der bereitgestellten Schleife. Die Semantik jedes Testsets ist ansonsten identisch mit der des begin/end-Falls (als ob es für jede Schleifeniteration verwendet wird).

@testset let

Wenn @testset let verwendet wird, startet das Makro ein transparentes Testset, wobei das gegebene Objekt als Kontextobjekt zu jedem fehlerhaften Test hinzugefügt wird, der darin enthalten ist. Dies ist nützlich, wenn eine Reihe verwandter Tests an einem größeren Objekt durchgeführt wird und es wünschenswert ist, dieses größere Objekt anzuzeigen, wenn einer der einzelnen Tests fehlschlägt. Transparente Testsets führen nicht zu zusätzlichen Ebenen der Verschachtelung in der Testset-Hierarchie und werden direkt an das übergeordnete Testset weitergegeben (mit dem Kontextobjekt, das an alle fehlerhaften Tests angehängt wird).

Beispiele

julia> @testset let logi = log(im)
           @test imag(logi) == π/2
           @test !iszero(real(logi))
       end
Test Failed at none:3
  Expression: !(iszero(real(logi)))
     Context: logi = 0.0 + 1.5707963267948966im

ERROR: Es gab einen Fehler während des Tests

julia> @testset let logi = log(im), op = !iszero
           @test imag(logi) == π/2
           @test op(real(logi))
       end
Test Failed at none:3
  Expression: op(real(logi))
     Context: logi = 0.0 + 1.5707963267948966im
              op = !iszero

ERROR: Es gab einen Fehler während des Tests

TestSetException

Wird ausgelöst, wenn ein Testset abgeschlossen ist und nicht alle Tests bestanden wurden.

@test_logs [log_patterns...] [keywords] Ausdruck

Sammeln Sie eine Liste von Protokolleinträgen, die durch Ausdruck generiert werden, indem Sie collect_test_logs verwenden, überprüfen Sie, ob sie mit der Sequenz log_patterns übereinstimmen, und geben Sie den Wert von Ausdruck zurück. Die keywords bieten eine einfache Filterung der Protokolleinträge: das min_level-Keyword steuert das minimale Protokollniveau, das für den Test gesammelt wird, das match_mode-Keyword definiert, wie das Matching durchgeführt wird (das Standard-:all überprüft, ob alle Protokolle und Muster paarweise übereinstimmen; verwenden Sie :any, um zu überprüfen, ob das Muster irgendwo in der Sequenz mindestens einmal übereinstimmt.)

Das nützlichste Protokollmuster ist ein einfaches Tupel der Form (level,message). Eine andere Anzahl von Tupel-Elementen kann verwendet werden, um andere Protokollmetadaten abzugleichen, die den Argumenten entsprechen, die an AbstractLogger über die Funktion handle_message übergeben werden: (level,message,module,group,id,file,line). Elemente, die vorhanden sind, werden standardmäßig paarweise mit den Feldern des Protokolleintrags unter Verwendung von == abgeglichen, wobei die Sonderfälle, dass Symbols für die Standardprotokollniveaus verwendet werden können, und Regexs im Muster die String- oder Symbolfelder mit occursin abgleichen.

Beispiele

Betrachten Sie eine Funktion, die eine Warnung protokolliert und mehrere Debug-Nachrichten:

function foo(n)
    @info "Doing foo with n=$n"
    for i=1:n
        @debug "Iteration $i"
    end
    42
end

Wir können die Info-Nachricht testen mit

@test_logs (:info,"Doing foo with n=2") foo(2)

Wenn wir auch die Debug-Nachrichten testen möchten, müssen diese mit dem min_level-Keyword aktiviert werden:

using Logging
@test_logs (:info,"Doing foo with n=2") (:debug,"Iteration 1") (:debug,"Iteration 2") min_level=Logging.Debug foo(2)

Wenn Sie testen möchten, dass bestimmte Nachrichten generiert werden, während der Rest ignoriert wird, können Sie das Keyword match_mode=:any setzen:

using Logging
@test_logs (:info,) (:debug,"Iteration 42") min_level=Logging.Debug match_mode=:any foo(100)

Das Makro kann mit @test verkettet werden, um auch den zurückgegebenen Wert zu testen:

@test (@test_logs (:info,"Doing foo with n=2") foo(2)) == 42

Wenn Sie auf das Fehlen von Warnungen testen möchten, können Sie die Angabe von Protokollmustern weglassen und das min_level entsprechend setzen:

# testen, dass der Ausdruck keine Nachrichten protokolliert, wenn das Logger-Niveau warn ist:
@test_logs min_level=Logging.Warn @info("Some information") # besteht
@test_logs min_level=Logging.Warn @warn("Some information") # schlägt fehl

Wenn Sie das Fehlen von Warnungen (oder Fehlermeldungen) in stderr testen möchten, die nicht durch @warn generiert werden, siehe @test_nowarn. ```

TestLogger(; min_level=Info, catch_exceptions=false)

Erstellen Sie einen TestLogger, der protokollierte Nachrichten in seinem Feld logs::Vector{LogRecord} erfasst.

Setzen Sie min_level, um das LogLevel zu steuern, catch_exceptions, um festzulegen, ob Ausnahmen, die im Rahmen der Protokollereigniserzeugung ausgelöst werden, erfasst werden sollen, und respect_maxlog, um festzulegen, ob die Konvention befolgt werden soll, Nachrichten mit maxlog=n für eine ganze Zahl n höchstens n Mal zu protokollieren.

Siehe auch: LogRecord.

Beispiele

julia> using Test, Logging

julia> f() = @info "Hi" number=5;

julia> test_logger = TestLogger();

julia> with_logger(test_logger) do
           f()
           @info "Bye!"
       end

julia> @test test_logger.logs[1].message == "Hi"
Test Passed

julia> @test test_logger.logs[1].kwargs[:number] == 5
Test Passed

julia> @test test_logger.logs[2].message == "Bye!"
Test Passed

LogRecord

Speichert die Ergebnisse eines einzelnen Protokollereignisses. Felder:

• level: das LogLevel der Protokollnachricht
• message: der textliche Inhalt der Protokollnachricht
• _module: das Modul des Protokollereignisses
• group: die Protokollgruppe (standardmäßig der Name der Datei, die das Protokollereignis enthält)
• id: die ID des Protokollereignisses
• file: die Datei, die das Protokollereignis enthält
• line: die Zeile innerhalb der Datei des Protokollereignisses
• kwargs: alle Schlüsselwortargumente, die an das Protokollereignis übergeben wurden

@inferred [ErlaubterTyp] f(x)

Testet, ob der Aufrufausdruck f(x) einen Wert des gleichen Typs zurückgibt, der vom Compiler abgeleitet wurde. Es ist nützlich, um die Typstabilität zu überprüfen.

f(x) kann jeder Aufrufausdruck sein. Gibt das Ergebnis von f(x) zurück, wenn die Typen übereinstimmen, und ein Error Result, wenn unterschiedliche Typen gefunden werden.

Optional lockert ErlaubterTyp den Test, indem er besteht, wenn entweder der Typ von f(x) mit dem abgeleiteten Typ modulo ErlaubterTyp übereinstimmt oder wenn der Rückgabetyp ein Subtyp von ErlaubterTyp ist. Dies ist nützlich, wenn man die Typstabilität von Funktionen testet, die eine kleine Vereinigung wie Union{Nothing, T} oder Union{Missing, T} zurückgeben.

julia> f(a) = a > 1 ? 1 : 1.0
f (generische Funktion mit 1 Methode)

julia> typeof(f(2))
Int64

julia> @code_warntype f(2)
MethodInstance für f(::Int64)
  von f(a) @ Main none:1
Argumente
  #self#::Core.Const(f)
  a::Int64
Body::UNION{FLOAT64, INT64}
1 ─ %1 = (a > 1)::Bool
└──      goto #3 if not %1
2 ─      return 1
3 ─      return 1.0

julia> @inferred f(2)
FEHLER: Rückgabetyp Int64 stimmt nicht mit abgeleitetem Rückgabetyp Union{Float64, Int64} überein
[...]

julia> @inferred max(1, 2)
2

julia> g(a) = a < 10 ? missing : 1.0
g (generische Funktion mit 1 Methode)

julia> @inferred g(20)
FEHLER: Rückgabetyp Float64 stimmt nicht mit abgeleitetem Rückgabetyp Union{Missing, Float64} überein
[...]

julia> @inferred Missing g(20)
1.0

julia> h(a) = a < 10 ? missing : f(a)
h (generische Funktion mit 1 Methode)

julia> @inferred Missing h(20)
FEHLER: Rückgabetyp Int64 stimmt nicht mit abgeleitetem Rückgabetyp Union{Missing, Float64, Int64} überein
[...]

@test_deprecated [pattern] expression

Wenn --depwarn=yes gesetzt ist, teste, dass expression eine Abwertungswarnung ausgibt und gib den Wert von expression zurück. Der Lognachricht-String wird mit pattern verglichen, das standardmäßig auf r"deprecated"i gesetzt ist.

Wenn --depwarn=no gesetzt ist, gib einfach das Ergebnis der Ausführung von expression zurück. Wenn --depwarn=error gesetzt ist, überprüfe, dass eine ErrorException ausgelöst wird.

Beispiele

# Abgewertet in julia 0.7
@test_deprecated num2hex(1)

# Der zurückgegebene Wert kann durch Verketten mit @test getestet werden:
@test (@test_deprecated num2hex(1)) == "0000000000000001"

@test_warn msg expr

Testen Sie, ob die Auswertung von expr zu einer stderr-Ausgabe führt, die den msg-String enthält oder mit dem msg-Regulären Ausdruck übereinstimmt. Wenn msg eine boolesche Funktion ist, wird getestet, ob msg(output) true zurückgibt. Wenn msg ein Tupel oder Array ist, wird überprüft, ob die Fehlermeldung jedes Element in msg enthält/übereinstimmt. Gibt das Ergebnis der Auswertung von expr zurück.

Siehe auch @test_nowarn, um das Fehlen von Fehlermeldungen zu überprüfen.

Hinweis: Warnungen, die von @warn erzeugt werden, können mit diesem Makro nicht getestet werden. Verwenden Sie stattdessen @test_logs.

@test_nowarn expr

Testen Sie, ob die Auswertung von expr zu leerem stderr Ausgabe (keine Warnungen oder andere Nachrichten) führt. Gibt das Ergebnis der Auswertung von expr zurück.

Hinweis: Das Fehlen von Warnungen, die von @warn erzeugt werden, kann mit diesem Makro nicht getestet werden. Verwenden Sie stattdessen @test_logs.

@test_broken ex
@test_broken f(args...) key=val ...

Kennzeichnet einen Test, der bestehen sollte, aber derzeit konstant fehlschlägt. Testet, ob der Ausdruck ex zu false evaluiert oder eine Ausnahme verursacht. Gibt ein Broken Result zurück, wenn dies der Fall ist, oder ein Error Result, wenn der Ausdruck zu true evaluiert. Dies entspricht @test ex broken=true.

Die Form @test_broken f(args...) key=val... funktioniert wie bei dem @test-Makro.

Beispiele

julia> @test_broken 1 == 2
Test Broken
  Expression: 1 == 2

julia> @test_broken 1 == 2 atol=0.1
Test Broken
  Expression: ==(1, 2, atol = 0.1)

@test_skip ex
@test_skip f(args...) key=val ...

Markiert einen Test, der nicht ausgeführt werden soll, aber in der Testzusammenfassung als Broken aufgeführt werden sollte. Dies kann nützlich sein für Tests, die sporadisch fehlschlagen, oder Tests von noch nicht implementierten Funktionen. Dies entspricht @test ex skip=true.

Die Form @test_skip f(args...) key=val... funktioniert wie bei dem @test-Makro.

Beispiele

julia> @test_skip 1 == 2
Test Broken
  Skipped: 1 == 2

julia> @test_skip 1 == 2 atol=0.1
Test Broken
  Skipped: ==(1, 2, atol = 0.1)

Test.Result

Alle Tests erzeugen ein Ergebnisobjekt. Dieses Objekt kann gespeichert werden oder auch nicht, abhängig davon, ob der Test Teil eines Testsets ist.

Test.Pass <: Test.Result

Die Testbedingung war wahr, d.h. der Ausdruck wurde als wahr ausgewertet oder die korrekte Ausnahme wurde ausgelöst.

Test.Fail <: Test.Result

Die Testbedingung war falsch, d.h. der Ausdruck wurde als falsch ausgewertet oder die korrekte Ausnahme wurde nicht ausgelöst.

Test.Error <: Test.Result

Die Testbedingung konnte aufgrund einer Ausnahme nicht ausgewertet werden oder sie wurde auf etwas anderes als ein Bool ausgewertet. Im Fall von @test_broken wird es verwendet, um anzuzeigen, dass ein unerwartetes Pass Result aufgetreten ist.

Test.Broken <: Test.Result

Die Testbedingung ist das erwartete (fehlgeschlagene) Ergebnis eines fehlerhaften Tests oder wurde ausdrücklich mit @test_skip übersprungen.

record(ts::AbstractTestSet, res::Result)

Ein Ergebnis zu einem Testset aufzeichnen. Diese Funktion wird von der @testset-Infrastruktur jedes Mal aufgerufen, wenn ein enthaltenes @test-Makro abgeschlossen ist, und erhält das Testergebnis (das ein Error sein könnte). Dies wird auch mit einem Error aufgerufen, wenn eine Ausnahme innerhalb des Testblocks, aber außerhalb eines @test-Kontexts ausgelöst wird.

finish(ts::AbstractTestSet)

Führen Sie alle erforderlichen Abschlussverarbeitungen für das gegebene Testset durch. Dies wird von der @testset-Infrastruktur aufgerufen, nachdem ein Testblock ausgeführt wurde.

Benutzerdefinierte AbstractTestSet-Untertypen sollten record auf ihrem übergeordneten Element (sofern vorhanden) aufrufen, um sich dem Baum der Testergebnisse hinzuzufügen. Dies könnte wie folgt implementiert werden:

if get_testset_depth() != 0
    # Fügen Sie dieses Testset dem übergeordneten Testset hinzu
    parent_ts = get_testset()
    record(parent_ts, self)
    return self
end

get_testset()

Rufen Sie das aktive Testset aus dem lokalen Speicher des Tasks ab. Wenn kein aktives Testset vorhanden ist, verwenden Sie das Standard-Testset als Fallback.

get_testset_depth()

Gibt die Anzahl der aktiven Testsets zurück, ohne das Standard-Testset einzuschließen.

TestCounts

Hält den Zustand für das rekursive Sammeln der Ergebnisse eines Testsets zu Anzeigezwecken.

Felder:

• customized: Ob die Funktion get_test_counts für das AbstractTestSet angepasst wurde, für das dieses Zählobjekt gedacht ist. Wenn eine benutzerdefinierte Methode definiert wurde, immer true an den Konstruktor übergeben.
• passes: Die Anzahl der bestandenen @test-Aufrufe.
• fails: Die Anzahl der fehlgeschlagenen @test-Aufrufe.
• errors: Die Anzahl der fehlerhaften @test-Aufrufe.
• broken: Die Anzahl der defekten @test-Aufrufe.
• passes: Die kumulierte Anzahl der bestandenen @test-Aufrufe.
• fails: Die kumulierte Anzahl der fehlgeschlagenen @test-Aufrufe.
• errors: Die kumulierte Anzahl der fehlerhaften @test-Aufrufe.
• broken: Die kumulierte Anzahl der defekten @test-Aufrufe.
• duration: Die Gesamtdauer, die das betreffende AbstractTestSet lief, als formatierter String.

" gettestcounts(::AbstractTestSet) -> TestCounts

Rekursive Funktion, die die Anzahl der Testergebnisse jedes Typs direkt im Testset zählt und die Gesamtzahlen über die untergeordneten Testsets summiert.

Benutzerdefinierte AbstractTestSet sollten diese Funktion implementieren, um ihre Gesamtzahlen zu zählen und zusammen mit DefaultTestSet anzuzeigen.

Wenn dies für ein benutzerdefiniertes TestSet nicht implementiert ist, fällt die Ausgabe auf die Berichterstattung von x für Fehler und ?s für die Dauer zurück.

format_duration(::AbstractTestSet)

Gibt einen formatierten String zurück, um die Dauer anzuzeigen, für die das Testset ausgeführt wurde.

Wenn nicht definiert, fällt es auf "?s" zurück.

print_test_results(ts::AbstractTestSet, depth_pad=0)

Druckt die Ergebnisse eines AbstractTestSet als formatierte Tabelle aus.

depth_pad bezieht sich darauf, wie viel Padding vor allen Ausgaben hinzugefügt werden soll.

Wird innerhalb von Test.finish aufgerufen, wenn das finishte Testset das oberste Testset ist.

Das GenericArray kann verwendet werden, um generische Array-APIs zu testen, die auf das AbstractArray-Interface abzielen, um sicherzustellen, dass Funktionen auch mit Array-Typen neben dem Standard-Array-Typ arbeiten können.

Der GenericDict kann verwendet werden, um generische Dict-APIs zu testen, die auf das AbstractDict-Interface abzielen, um sicherzustellen, dass Funktionen auch mit assoziativen Typen neben dem Standardtyp Dict arbeiten können.

Der GenericOrder kann verwendet werden, um APIs auf ihre Unterstützung für generische geordnete Typen zu testen.

Das GenericSet kann verwendet werden, um generische Set-APIs zu testen, die auf das AbstractSet-Interface abzielen, um sicherzustellen, dass Funktionen auch mit Set-Typen neben den Standardtypen Set und BitSet funktionieren.

Der GenericString kann verwendet werden, um generische String-APIs zu testen, die auf das AbstractString-Interface abzielen, um sicherzustellen, dass Funktionen mit String-Typen neben dem Standard-String-Typ arbeiten können.

detect_ambiguities(mod1, mod2...; recursive=false,
                                  ambiguous_bottom=false,
                                  allowed_undefineds=nothing)

Gibt ein Vektor von (Method,Method)-Paaren von mehrdeutigen Methoden zurück, die in den angegebenen Modulen definiert sind. Verwenden Sie recursive=true, um in allen Untermodulen zu testen.

ambiguous_bottom steuert, ob Mehrdeutigkeiten, die nur durch Union{}-Typparameter ausgelöst werden, einbezogen werden; in den meisten Fällen möchten Sie dies wahrscheinlich auf false setzen. Siehe Base.isambiguous.

Siehe Test.detect_unbound_args für eine Erklärung von allowed_undefineds.

detect_unbound_args(mod1, mod2...; recursive=false, allowed_undefineds=nothing)

Gibt einen Vektor von Methods zurück, die möglicherweise ungebundene Typparameter haben. Verwenden Sie recursive=true, um in allen Untermodulen zu testen.

Standardmäßig lösen alle undefinierten Symbole eine Warnung aus. Diese Warnung kann unterdrückt werden, indem eine Sammlung von GlobalRefs bereitgestellt wird, für die die Warnung übersprungen werden kann. Zum Beispiel, wenn Sie

allowed_undefineds = Set([GlobalRef(Base, :active_repl),
                          GlobalRef(Base, :active_repl_backend)])

setzen, würden Warnungen über Base.active_repl und Base.active_repl_backend unterdrückt.