Man verwendet den Ausdruck Modultest unter anderem bei frühen Teststufen, in denen man die inneren, detailliertesten Komponenten der Software testet. Gemäß Software Validation & Verification Plan sind diese Tests nur für Module mit geringer Kritikalität nicht notwendig. Im Grunde genommen bei Fehlern, die dem User nur geringfügige Unannehmlichkeiten bereiten.

In einer Abstraktion der verwendeten Programmiersprache, spricht man von Komponente oder Softwarebaustein. Den Test eines solchen einzelnen Softwarebausteins bezeichnet man auch allgemeiner als Komponententest.

Als Testbasis kann man in der Regel die komponentenspezifische Anforderung und das Softwaredesign der Komponente (auch Komponentenspezifikation genannt) heranziehen. Für Whitebox-Testfälle oder um Aussagen zur Codeüberdeckung zu erhalten, kann man zusätzlich den Sourcecode einer Komponente analysieren und diesen als Testbasis verwenden. Wobei dabei auch Tools wie Jacoco helfen können. Ob die Komponente auf einen Testfall richtig reagiert, muss man allerdings auch hier auf Basis der Design- und Anforderungsdokumente beurteilen.

Typische Testobjekte sind wie bereits beschrieben Programmunits, -Module bzw. Klassen. Aber auch Kommandozeilenskripte des Betriebssystems (Shell-Skripte), Datenbankskripte, Datenkonvertierungs- oder Migrationsprozeduren, Datenbankinhalte sowie Konfigurationsdaten können Testobjekte sein. Kennzeichnend ist in der Regel der isolierte Test eines einzelnen Softwarebausteins. Dies dient primär, um komponentenexterne Einflüsse beim Testen auszuschließen. Alle so ermittelten Fehler kann man so dem spezifischen Modul zuordnen.

Klar zu unterscheiden ist auf jeden Fall der Integrationstest, den ich in einem separaten Beitrag thematisiere. Bei einem Integrationstest konzentriert man sich auf die Wechselwirkung mit Nachbarkomponenten.

Die Erstellung solcher Tests ist in der Regel die Aufgabe eines Programmierers. Dies liegt zum einen daran, dass man ein ausgeprägtes Verständnis für die Programmiersprache in der die Anwendung geschrieben ist haben muss. Und zum anderen daran, dass man meist auch einen Testtreiber benötigt, dessen Programmierung in der Regel auch der Entwickler übernimmt.

Einordnung im Testprozess

Algorithmen auf Unitebene besitzen meist nur eine begrenzte Komplexität und man kann sie über klar definierte Schnittstellen aktivieren. Daher kann sie mit relativ wenigen Testfällen weitgehend vollständig testen. Dies gilt als Voraussetzung für die anschließende Teststufe. Dem Integrationstest, um dort die Testfälle auf das integrierte Zusammenwirken größerer Funktionsteile oder der gesamten Anwendung ausrichten zu können. Die modulspezifischen Detailkonstellationen lassen sich damit auf Stichproben beschränken, was die Anzahl der erforderlichen Testfälle signifikant reduziert.

Zum Vergleich: Ein Gerät wird erst dann als Ganzes getestet, wenn die Funktionsfähigkeit seiner Einzelteile gesichert ist.

Test des Vertrages und nicht der Algorithmen

Man testet bei Modultests gemäß dem Design-by-contract-Prinzip möglichst nicht die Interna einer Methode, sondern nur ihre externen Auswirkungen (Rückgabewerte, Ausgaben, Zustandsänderungen, Zusicherungen). Sind die internen Details der Methode geprüft (dies wird als White-Box-Testing bezeichnet), kann der Test fehlschlagen, obwohl sich die externen Auswirkungen nicht geändert haben. Daher empfiehlt man in der Regel das sogenannte Black-Box-Testing, bei dem man sich auf das Prüfen der externen Auswirkungen beschränkt.

Was sind die Vorteile von Unit Tests?

• Mittels automatisierter Unittests kann man im Schnitt 30 % der Fehler erkennen. Bei der Verwendung von TDD (Test Driven Development) kann man im Schnitt 45 % und im besten Fall 85 % der Fehler vermeiden.
• Fehler erkennt man durch Modultests bereits während der Entwicklung. Die durch Unittests vermiedenen Fehlerkosten sind daher gemäß der Rule of Ten (Dazu später mehr) um ein Vielfaches höher als bei späteren Teststufen, was Unittests zur effizientesten Teststufe machen.
• Im Falle eines Fehlers kann man diesen sehr viel genauer eingrenzen und damit schneller finden und beheben.
• Die Tests erfüllen den Zweck einer lebenden Dokumentation. In Kombination mit einer sinnvollen Benamung der Objekte (Clean Code) können zusätzliche Dokumentationsmaßnahmen entfallen.
• Da einzelne Module nur wenige mögliche Codeausführungspfade besitzen, muss man viel weniger mögliche kombinatorische Ausführungspfade berücksichtigen als bei anderen Testarten. Bei übergeordneten Tests kann man sich dann stichprobenartig auf die wichtigsten Ausführungspfade konzentrieren und damit die Anzahl dieser Tests deutlich reduzieren.
• Da man nur einzelne Module testet, kann man Modultests, oft um mehrere Größenordnungen, schneller und damit öfter (bzw. kontinuierlich) ausführen als andere Testarten.
• Wenn man Fehler mit einem Test absichert, kann man den erneuten Auftritt des gleichen Fehlers verhindern.
• Durch die Fehlerreduktion ergeben sich Geschwindigkeitsvorteile in der Entwicklung in mittleren bis großen Softwareprojekten.
• Da man Abhängigkeiten zwingend vermeiden muss, um einen Modultest zu ermöglichen, bleibt der Code verhältnismäßig schnell änderbar. Hierdurch kann man schneller auf wechselnde Anforderungen reagieren. Siehe Agile Manifest 😉
• Da automatisch ausgeführte Tests um mehrere Größenordnungen schneller sind als manuelle Tests, reduziert sich der Zeitaufwand für das Testen deutlich. Hierdurch kann man die Entwicklungsstufen schneller durchlaufen und die Release-Zyklen signifikant verkürzen.

Was sind die Nachteile von Unit Tests?

• Bei der Implementierung neuer Funktionen muss man nicht nur die Funktion implementieren, sondern auch die dazugehörenden Tests vorbereiten bzw. definieren. Dadurch ergibt sich ein oft mehrfacher Implementierungsaufwand.
• Bei Änderungen muss man nicht nur die geänderten Funktionen, sondern auch die dazugehörenden Tests anpassen. Insbesondere bei der Entwicklung von Prototypen, bei der sich die Codebasis schnell verändert, ist das Testen daher oft eher ein Hindernis.
• Da man die Funktionalität der Tests verwendet, ist in den IDEs schwerer ersichtlich, ob eine Funktionalität keine Verwendung mehr findet und ob man es daher entfernen kann.
• Weisen die Tests untereinander Abhängigkeiten auf (z. B. durch gemeinsame Testdaten), so können einzelne Änderungen an der Codebasis eine Vielzahl von Tests beeinflussen, was den Änderungsaufwand mit der Größe der Codebasis exponentiell erhöht.

Fehlerkosten 10er Regel (Rule of ten)

Die Zehnerregel der Fehlerkosten besagt, dass je weiter ein Fehler sich unentdeckt in die späten Phasen des Werdegangs eines Produktes oder Prozesses bewegt – oder gar bis zum Kunden –, desto höher steigen die Kosten zur Behebung des Fehlers. Eindrucksvoll untermauert durch die Ergebnisse einiger Studien aus den 70er Jahren in Japan, USA und Großbritannien, die sich mit den Ursachen von Produkt- bzw. Qualitätsmängeln beschäftigten. Alle Analysen lieferten nahezu die gleichen Ergebnisse: Ca. 70 % aller Produktmängel hatten ihre Ursache bereits in der Entwicklung, Konstruktion und Arbeitsvorbereitung. Der Herstellungsprozess selbst hat bezüglich der Endqualität des Produktes offensichtlich eher einen sekundären Einfluss. Eine VDMA-Studie zum Thema „Qualitätsbezogene Kosten“ Anfang der 90er Jahre in der Bundesrepublik Deutschland bestätigt dieses Ergebnis.

Die Zehnerregel der Fehlerkosten oder „Rule of ten“ sagt aus, dass sich die Fehlerkosten für einen nicht entdeckten Fehler von Stufe zu Stufe der Wertschöpfung um den Faktor 10 erhöhen. Je früher ein Fehler entdeckt und beseitigt wird, desto kostengünstiger ist dies für die Organisation und schlussendlich auch für den User bzw. Kunden.

Ansonsten sind diese auch in der DIN 55350-11 im Rahmen des Qualitätsmanagements festgehalten. Doch darauf gehe ich in einem separaten Beitrag ein.

Wo sind die Grenzen der Unit Tests?

Unit Tests können (wie jeder Test) die Fehlerfreiheit der getesteten Units, Module usw. nicht garantieren oder nachweisen, sondern lediglich unterstützen. Die Grenzen von Unit Tests liegen primär nur in den Fällen vor in denen man Fehler finden kann, zu deren Entdeckung die verwendeten Tests geeignet sind. Eine Softwarekomponente, die „grün“ testet, ist also nur bedingt fehlerfrei.

Das Merkmal von Code, „grün“ zu testen, und durchaus auch der Wunsch nach diesem Ergebnis, kann dazu führen, dass man tatsächlich (unbewusst) nur so viel testet, bis alle Tests „grün“ sind. Module, die keine fehlschlagenden Modultests haben, als fehlerfrei zu behandeln, ist ein Fehlschluss in der Praxis des (TDD) Test Driven Development.

Um eine ausreichende Testabdeckung zu erzielen, lohnt es sich u.U., vor dem Erstellen der Testfälle Refactoring-Maßnahmen anzuwenden. Dies erst nach abgeschlossenen Unit Tests (für den alten Code) zu tun, schafft Raum (wie jede Änderung im Code) für neue Fehlerrisiken und kann deshalb wiederholtes Testen erforderlich machen.

Wenn der Autor von Unit Tests mit dem Autor der Module identisch ist, können Denkfehler in der Implementierung auch im Test erscheinen und verpasst gegebenenfalls die Chance, diese aufzudecken. Wenn es sich um dieselbe Person handelt, kann man die vorrangige Entwicklung der Tests ebenfalls nicht garantieren, da sowohl die beabsichtigte Funktionsweise des Codes als auch die zukünftige Gestalt bereits im Gedankengut des Testautors und späteren Codeautors präsent sein können. Dies kann im Extreme Programming durch „Test Ping-Pong“ abgefangen werden, bei der sich Entwickler bei der Implementierung der Funktionalität und der Tests abwechseln.

Bei der Entwicklung von Modultests können Testfälle entstehen, die der Zielsetzung und dem Charakter von Modultests nicht oder nur zum Teil entsprechen. Wie bei der Programmierung existieren daher auch für die Entwicklung von Modultests Anti-Pattern, die man möglichst vermeiden sollte.

Der Beitrag Unit Tests – Fundament für stabile und effiziente Software erschien zuerst auf CEOsBay.

Während NFTs mit der Blockchain dieselbe Technologie benutzen wie Kryptowährungen, sind sie im Unterschied zu diesen einmalig und nicht teilbar (Daher non-fungible „nicht austauschbar“). Ein NFT kann nur als Ganzes erworben werden und existiert nur ein einziges Mal – anders als bei der Möglichkeit, beispielsweise 0,1 Ethereum zu erwerben, bei der es für den Wert keine Rolle spielt, an welchem davon man einen Anteil erwirbt.

Smart Contracts und NFT?

Smart Contracts verwalten die NFTs. Ein NFT enthält meist nur einen Verweis bzw. eine URL auf einen digitalen Inhalt. Der digitale Inhalt selbst ist auf einem Server gespeichert bzw. gehostet. Welcher Art die Rechte sind, die mit dem Erwerb eines NFTs verbunden sind, ist nicht einheitlich geregelt. Nichtübertragbar sind Durchsetzbare Rechte wie etwa das Urheberrecht bzw. Verwertungsrecht an einem Lied oder die Besitzrechte an einem physischen Objekt, dessen Abbildung man handelt. Siehe Urheberrecht in den gängigen Gesetzbüchern.

Validität und Integrität der NFT

Auch hat ein NFT keine Aussagekraft über die Validität und Integrität der digitalen Ressource. Es verweist lediglich darauf, unabhängig davon von der Existenz oder Modifikation der Datei. Damit sind im Grunde genommen Probleme vorprogrammiert. Wenn beispielsweise Server offline gehen und die mit den NFTs verknüpften Dateien nicht mehr abrufbar sind. Oder durch die Manipulation der Dateien. Böswillige Nutzer können Verknüpfungen zu den Dateien in anderen Blockchains erstellen und verkaufen sie.

Non-Fungible Token können dort verwendet werden, wo virtuellen Gütern ein Etikett zugeordnet wird. Sie können dabei als Nachweis bestimmter Rechte an den Objekten selbst gesammelt und gehandelt werden. Dies betrifft zum Beispiel digitale Kunst, Musik oder Einzelobjekte in Computerspielen oder DApps (Dezentralisierte Anwendungen). NFTs können auch die Funktion einer Eintrittskarte oder eines Mitgliedsausweises erfüllen. Die Urheber der NFTs können den Käufern bzw. Besitzern erlauben, die Motive ihrer erworbenen NFTs kommerziell zu verwerten, wie man es aus diversen NFT-Projekten kennt.

KYC – Know Your Customer

Der Handel mit NFTs findet auf Handelsplattformen statt. Diese führen die Transaktionen auf Basis der Blockchain oder einer günstigeren Zwischenschicht (Sidechains) aus. Hierfür ist eine Identifikation der Käufer und Verkäufer in Form ihrer Kryptowallets notwendig. Derzeit wird an einem Gesetzesentwurf gearbeitet, dass alle verpflichten soll, einen sogenannten KYC zu machen. Know Your Customer – Kenne Deinen Kunden. Wie bei Kreditinstituten und Versicherungen wird eine vorgeschriebene Legitimationsprüfung von bestimmten Neukunden zur Verhinderung von Geldwäsche vorgenommen.

Was in Anbetracht der hohen Betrugszahlen bei vielen Blockchainanwendungen gar nicht so schlecht ist. Dennoch stellt ein solcher Prozess alle User unter einen gewissen Generalverdacht, was ich persönlich nicht gutheißen kann. Nachdem ich aber selbst schon Opfer der ein oder anderen Betrugsmasche geworden bin und meine Steuern auch gerne bezahle, wenn die Steuereinnahmen des Staates in der Regel für gute Dinge wie Bildung investiert werden, schätze ich diese Praxis als tragbar ein. Vor allem wenn man bedenkt, dass Smart Contracts wirklich einen Mehrwert für die Gesellschaft als solches bieten können. Dazu aber mehr, wenn ich explizit über Smart Contracts schreibe. Auf jeden Fall können wir festhalten, dass Gewinne aus dem Handel mit NFTs als Veräußerungsgewinne versteuert werden müssen.

Ethereum und die Sidechains

NFTs werden von einigen Blockchainprojekten unterstützt. Die (Stand November 2022) am häufigsten für NFTs genutzte Blockchain ist nach wie vor Ethereum. Neben Ethereum werden die Side-Chains genutzt. Eine Sidechain ist eine separate Blockchain, die unabhängig von Ethereum läuft. Sie wird über eine Zwei-Wege-Brücke mit dem Ethereum Mainnet verbunden. Sidechains können eigene Blockparameter und Konsensalgorithmen haben, die oft für eine effiziente Verarbeitung von Transaktionen ausgelegt sind.

Der Beitrag NFT – Non-Fungible Token – Einzigartigkeit und Besitz im digitalen Zeitalter durch revolutionäre Blockchain-Technologie erschien zuerst auf CEOsBay.