---
title: Automatische Unit-Tests
layout: default
root: ../..
idx: 8.5
---

## Einleitung <!-- omit in toc -->

Unit-Tests sind ein wichtiges Instrument, um zu beweisen und sich zu vergewissern, dass der Code korrekt ist. Dieses Kapitel zeigt Ihnen, wie Sie Tests für Minetest-Mods und Spiele mit Busted schreibt. Das Schreiben von Unit-Tests für Funktionen, die Minetest Funktionen aufruft, ist ziemlich schwierig, aber zum Glück haben wir [im vorherigen Kapitel](clean_arch.html), besprochen, wie man seinen Code strukturiert, um dies zu vermeiden.

- [Busted installieren](#busted-installieren)
- [Ihr erster Test](#ihr-erster-test)
  - [init.lua](#initlua)
  - [api.lua](#apilua)
  - [tests/api_spec.lua](#testsapispeclua)
- [Mocking: Externe Funktionen verwenden](#mocking-externe-funktionen-verwenden)
- [Überprüfen von Commits mit Travis](#berprfen-von-commits-mit-travis)
- [Zusammenfassung](#zusammenfassung)

## Busted installieren

Zuerst müssen Sie LuaRocks installieren.

* Windows: Folgen Sie den [Installationsanweisungen im LuaRock-Wiki](https://github.com/luarocks/luarocks/wiki/Installation-instructions-for-Windows).
* Debian/Ubuntu Linux: `sudo apt install luarocks`

Als nächstes sollten Sie Busted global, also für alle Benutzer, installieren:

    sudo luarocks install busted

Prüfen Sie schließlich, ob es installiert ist:

    busted --version


## Ihr erster Test

Busted ist das führende Unit-Test-Framework für Lua. Busted sucht nach Lua-Dateien mit Namen, die auf `_spec` enden und führt sie dann in einer eigenständigen Lua-Umgebung aus.

    mymod/
    ├── init.lua
    ├── api.lua
    └── tests
        └── api_spec.lua


### init.lua

```lua
mymod = {}

dofile(minetest.get_modpath("mymod") .. "/api.lua")
```



### api.lua

```lua
function mymod.add(x, y)
    return x + y
end
```

### tests/api_spec.lua

```lua
-- Suchen Sie nach erforderlichen Dingen in
package.path = "../?.lua;" .. package.path

-- Setzen von mymod global für API zum Schreiben in
_G.mymod = {} --_
-- Ausführen von api.lua-Datei
require("api")

-- Tests
describe("add", function()
    it("adds", function()
        assert.equals(2, mymod.add(1, 1))
    end)

    it("supports negatives", function()
        assert.equals(0,  mymod.add(-1,  1))
        assert.equals(-2, mymod.add(-1, -1))
    end)
end)
```

Sie können die Tests nun ausführen, indem Sie ein Terminal im Verzeichnis des Mods öffnen und `busted` ausführen.

Es ist wichtig, dass die API-Datei die Tabelle nicht selbst erstellt, da Globals in Busted anders funktionieren. Jede Variable, die in Minetest global wäre, ist stattdessen
eine lokale Datei in Busted. Dies wäre ein besserer Weg für Minetest gewesen, die Dinge zu erledigen, aber dafür ist es jetzt zu spät.

Eine weitere Sache, die man beachten sollte, ist, dass alle Dateien, die man testet, keine Aufrufe an irgendwelche Funktionen vermeiden, die nicht darin enthalten sind. In der Regel schreibt man nur Tests für eine einzige Datei auf einmal.


## Mocking: Externe Funktionen verwenden

Beim Mocking werden die Funktionen ersetzt, von denen das zu testende Objekt abhängt. Dies kann zwei Zwecke haben: Erstens ist die Funktion in der Testumgebung möglicherweise nicht verfügbar Testumgebung nicht zur Verfügung und zweitens möchten Sie vielleicht die Aufrufe der Funktion und alle übergebenen Argumente.

Wenn Sie die Ratschläge im Kapitel [Saubere Architekturen](clean_arch.html) befolgen,
haben Sie bereits eine ziemlich saubere Datei zum Testen. Sie müssen jedoch noch
Dinge, die nicht in Ihrem Bereich liegen, mocken - zum Beispiel müssen Sie den View mocken, wenn Sie Controller/API testen. Wenn Sie die Ratschläge nicht befolgt haben, ist es etwas etwas schwieriger, da Sie möglicherweise die Minetest-API nachbilden müssen.

```lua
--  Wie oben eine Tabelle erstellen
_G.minetest = {}

-- Definieren Sie die Mock-Funktion
local chat_send_all_calls = {}
function minetest.chat_send_all(name, message)
    table.insert(chat_send_all_calls, { name = name, message = message })
end

-- Tests
describe("list_areas", function()
    it("returns a line for each area", function()
        chat_send_all_calls = {} -- reset table

        mymod.list_areas_to_chat("singleplayer", "singleplayer")

        assert.equals(2, #chat_send_all_calls)
    end)

    it("sends to right player", function()
        chat_send_all_calls = {} -- reset table

        mymod.list_areas_to_chat("singleplayer", "singleplayer")

        for _, call in pairs(chat_send_all_calls) do --_
            assert.equals("singleplayer", call.name)
        end
    end)

    -- Die beiden oben genannten Tests sind eigentlich sinnlos,
    --   denn dieser testet beide Dinge
    it("returns correct thing", function()
        chat_send_all_calls = {} -- reset table

        mymod.list_areas_to_chat("singleplayer", "singleplayer")

        local expected = {
            { name = "singleplayer", message = "Town Hall (2,43,63)" },
            { name = "singleplayer", message = "Airport (43,45,63)" },
        }
        assert.same(expected, chat_send_all_calls)
    end)
end)
```


## Überprüfen von Commits mit Travis

Das Travis-Skript aus dem Kapitel [Automatische Fehlerüberprüfung](luacheck.html) kann so modifiziert werden, dass es auch Busted ausführt.

```yml
language: generic
sudo: false
addons:
  apt:
    packages:
    - luarocks
before_install:
  - luarocks install --local luacheck && luarocks install --local busted
script:
- $HOME/.luarocks/bin/luacheck .
- $HOME/.luarocks/bin/busted .
notifications:
  email: false
```


## Zusammenfassung

Unit-Tests können die Qualität und Zuverlässigkeit Ihres Projekts erheblich steigern. Diese erfordern jedoch, dass Sie Ihren Code anders strukturieren als üblich.

Ein Beispiel für einen Mod mit vielen Unit-Tests finden Sie unter
[crafting by rubenwardy](https://github.com/rubenwardy/crafting).