2016-09-05 5 views
0

Ich schreibe gerade Komponententests für eine Lua Mod-Bibliothek mit Busted. Die fragliche Datei definiert ein Modul mit einigen Funktionen und ruft dann eine dieser Funktionen unten auf, um sich selbst zu initialisieren.Testcode sofort in einem Skript aufgerufen

Das Problem, das ich finde, ist, dass Busted scheint, die required-in-Datei zweimal zu bewerten.

-Test

it('does a thing', function() 
    -- Some setup, replacing globals etc 
    require('items') 
    assert.are_equal(2, #Items._registry) 
end) 

Modul

Items = { _registry = {} } 
function Items.do_some_stuff() end 
function some_util_func() end 
function load_registry() 
    print(debug.traceback()) 
    for i, itm in pairs(Items.do_some_stuff()) do 
    Items._registry[i] = itm 
    end 
end 

load_registry() 

Wie Sie sehen können, obwohl ich den Code und Namen vereinfacht haben, ist die Struktur nichts aus heiterem Himmel (wie ich verstehen.)

Der Test wird immer fehlschlagen, weil #Items._registry ist immer ys 0 (und Dumping auf die Konsole überprüft dies). Ich habe versucht, innerhalb der Methode zu drucken und fand es zweimal gedruckt; dann habe ich versucht, debug.traceback an der Spitze dieser Salbung zu verwenden und fand das unten. Wie Sie sehen können, wird die Stapelrückverfolgung zweimal gedruckt, was darauf hindeutet, dass der Code zweimal ausgewertet wird.

Ist das etwas, auf das irgendjemand sonst gestoßen ist? Strukturiere ich meinen Test falsch für dieses Szenario? Oder das ein Fehler?


stack traceback: 
    items.lua:96: in function 'load_registry' 
    items.lua:109: in main chunk 
    [C]: in function 'require' 
    spec/items_pec.lua:50: in function <spec/items_spec.lua:39> 
    [C]: in function 'xpcall' 
    /usr/local/share/lua/5.2/busted/core.lua:178: in function 'safe' 
    /usr/local/share/lua/5.2/busted/init.lua:40: in function 'executor' 
    /usr/local/share/lua/5.2/busted/core.lua:312: in function </usr/local/share/lua/5.2/busted/core.lua:312> 
    [C]: in function 'xpcall' 
    /usr/local/share/lua/5.2/busted/core.lua:178: in function 'safe' 
    ... 
    /usr/local/share/lua/5.2/busted/core.lua:312: in function 'execute' 
    /usr/local/share/lua/5.2/busted/block.lua:155: in function 'execute' 
    /usr/local/share/lua/5.2/busted/init.lua:7: in function 'executor' 
    /usr/local/share/lua/5.2/busted/core.lua:312: in function </usr/local/share/lua/5.2/busted/core.lua:312> 
    [C]: in function 'xpcall' 
    /usr/local/share/lua/5.2/busted/core.lua:178: in function 'safe' 
    /usr/local/share/lua/5.2/busted/core.lua:312: in function 'execute' 
    /usr/local/share/lua/5.2/busted/execute.lua:58: in function 'execute' 
    /usr/local/share/lua/5.2/busted/runner.lua:174: in function </usr/local/share/lua/5.2/busted/runner.lua:11> 
    /usr/local/lib/luarocks/rocks/busted/2.0.rc12-1/bin/busted:3: in main chunk 
    [C]: in ? 
stack traceback: 
    items.lua:96: in function 'load_registry' 
    items.lua:109: in main chunk 
    [C]: in function 'require' 
    spec/items_spec.lua:15: in main chunk 
    [C]: in function 'xpcall' 
    /usr/local/share/lua/5.2/busted/core.lua:178: in function 'safe' 
    /usr/local/share/lua/5.2/busted/block.lua:146: in function 'execute' 
    /usr/local/share/lua/5.2/busted/init.lua:7: in function 'executor' 
    /usr/local/share/lua/5.2/busted/core.lua:312: in function </usr/local/share/lua/5.2/busted/core.lua:312> 
    [C]: in function 'xpcall' 
    /usr/local/share/lua/5.2/busted/core.lua:178: in function 'safe' 
    /usr/local/share/lua/5.2/busted/core.lua:312: in function 'execute' 
    /usr/local/share/lua/5.2/busted/execute.lua:58: in function 'execute' 
    /usr/local/share/lua/5.2/busted/runner.lua:174: in function </usr/local/share/lua/5.2/busted/runner.lua:11> 
    /usr/local/lib/luarocks/rocks/busted/2.0.rc12-1/bin/busted:3: in main chunk 
    [C]: in ? 
+0

Es ist schwer zu sagen, was hier vor sich geht, da sich Ihre Stack-Trace nicht auf Ihren vereinfachten Code bezieht, und wir wissen nicht, was load_registry tut. Ich würde empfehlen, Ihr Modul mit dem neuen Stil zu refactoring: http://lua-users.org/wiki/ModulesTutorial –

+0

Messepunkt. Ich habe eine Implementierung für die 'load_registry'-Funktion hinzugefügt und die Namen im Stack-Trace so bearbeitet, dass sie mit dem Beispiel übereinstimmen. – AndyBursh

+0

Ich habe Ihr Beispiel lokal ausprobiert und erhalte nur eine Ausgabe. Welchen Befehl führen Sie zum Testen aus? Gibt es einen anderen Code, der Probleme verursachen könnte? –

Antwort

1

Die Antwort auf diese Frage lag im Detail dachte, ich war fremd war aber nicht (siehe meine comment).

Insbesondere habe ich Tests für das Modul-Lastverhalten von den Tests für seine verschiedenen Funktionen getrennt. Selbst wenn mit busted -t als Ziel für einen bestimmten Test gearbeitet wurde, wurden die Importe des zu testenden Moduls in beiden Spezifikationen bewertet; auch wenn der Aufruf in der setup Funktion für den Stamm describe Block platziert wurde.

Durch die Zusammenführung der beiden Spezifikationen konnte ich diese doppelte Belastung umgehen.

Verwandte Themen