Die Wurzeln des Pestizid-Paradoxons liegen in der Landwirtschaft. Wenn ein Bauer ständig dasselbe Pestizid verwendet, um seine Ernte zu schützen, entwickeln schließlich die Schädlinge, die überleben, eine Immunität gegen dieses spezifische Pestizid. Im Laufe der Zeit verliert das Pestizid seine Wirksamkeit. Analog dazu, in der Softwareentwicklung, wenn Entwickler und Tester immer wieder dieselben Tests anwenden, werden sie nur die Fehler finden und beheben, die diese Tests identifizieren können.

Das Pestizid-Paradoxon in der Softwareentwicklung verweist also auf die Notwendigkeit, kontinuierlich neue und verschiedene Testfälle zu erstellen. In der modernen agilen Entwicklung (Siehe Beitrag „Agiles Manifest„), bei der man Software kontinuierlich ändert und verbessert, muss das Testen Schritt halten und sich anpassen.

Mit der Zeit entdecken Testfälle weniger und weniger Bugs, genau wie Pestizide, die ihre Wirksamkeit gegen Schädlinge verlieren. Um Qualität und Sicherheit zu gewährleisten, muss man die Testszenarien daher regelmäßig überprüfen und aktualisieren. Ebenso muss man neue Tests entwickeln, um auf veränderte oder neue Funktionen zu reagieren.

Ein weiterer zentraler Aspekt des Pestizid-Paradoxons in der Softwareentwicklung ist die Notwendigkeit einer vielfältigen Teststrategie. Dazu gehören Funktionstests, Integrationstests, Leistungstests, Sicherheitstests und Benutzerakzeptanztests. Ein vielfältiges Test-Portfolio, das verschiedene Aspekte und Ebenen der Software abdeckt, erhöht die Wahrscheinlichkeit, dass mehr Fehler entdeckt und behoben werden.

Das Pestizid-Paradoxon ist somit eine starke Erinnerung daran, dass Veränderung in der Softwareentwicklung nicht nur unausweichlich, sondern notwendig ist. Es lehrt uns, dass wir uns nicht auf bewährte Testverfahren verlassen sollten. Es macht Sinn, ständig neue Methoden und Ansätze zu entwickeln und anzuwenden, um Softwarequalität und -sicherheit zu gewährleisten.

Der Beitrag Pestizid-Paradoxon – Resistenz von Bugs und Fehlern erschien zuerst auf CEOsBay.

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.

1. Autokonfiguration
2. Ein Opinionated-Konfigurationsansatz
3. Die Fähigkeit, eigenständige Anwendungen zu erstellen

Das Zusammenspiel dieser Funktionen ermöglicht die Installation einer Spring basierten Anwendung mit minimalem Konfigurations- bzw. Einrichtungsaufwand, worauf ich nachfolgend näher eingehe. Mit einem breiten Spektrum an Funktionalitäten ist es eine ganzheitliche Lösung, wobei die Entkopplung der Applikationskomponenten im Vordergrund steht.

Was ist das Spring Framework und was stellt Spring Boot damit an?

Ein Spring Framework bietet eine Abhängigkeitsinjektionsfunktion, mit der Objekte ihre eigenen Abhängigkeiten definieren können.Der Spring-Container injiziert diese nachfolgend. So kann man als Entwickler modulare Anwendungen erstellen, die aus losen verbundenen Komponenten bestehen. Diese eignen sich ideal für Microservices und verteilte Netzanwendungen.

Das Spring Framework bietet auch die integrierte Unterstützung für typische Aufgaben, die eine Anwendung ausführen muss. Beispiele hierfür sind Datenbindung, Typumsetzung, Prüfung und Bewertung, Ausnahmebehandlung, Ressourcen- und Ereignismanagement und vielem mehr. Darüber hinaus lässt es sich mit verschiedenen Java EE-Technologien wie RMI (Remote Method Invocation), AMQP (Advanced Message Queuing Protocol), Java Web Services und anderen integrieren. Alles in allem liefert das Spring Framework Entwicklern alle Tools und Funktionen, die man benötigt, um lose verbundene, plattformunabhängige Java EE-Anwendungen zu erstellen, die man in den verschiedensten Umgebungen ausführen kann. So leistungsfähig und umfassend das Spring Framework auch ist, so viel Zeit und Know-How erfordert es, Spring-Anwendungen sauber zu konfigurieren, einzurichten und bereitzustellen. Spring Boot verringert diesen Aufwand mit den bereits zu Beginn erwähnten drei wichtigen Funktionen.

Autokonfiguration in Spring Boot

Unter der Autokonfiguration verstehen man die Initialisierung von Anwendungen mit voreingestellten Abhängigkeiten ohne den manuellen Eingriff eines Entwicklers. Da Java Spring Boot über integrierte Autokonfigurationsfunktionen verfügt, konfiguriert es sowohl das zugrunde liegende Spring Framework als auch die Pakete von Drittanbietern automatisch auf der Grundlage der eigenen individuellen Einstellungen. Dies trägt auch zur grundlegenden Fehlervermeidung bei. Auch wenn man die Standardeinstellungen nach Abschluss der Initialisierung überschreiben kann, ermöglicht die Autokonfigurationsfunktion von Java Spring Boot einen schnellen Start bei der Entwicklung von Spring-basierten Anwendungen. Dies reduziert die Möglichkeit menschlicher Fehler.

Opinionated-Konfigurationsansatz

Der Optionated-Ansatz bei Spring Boot findet Anwendung beim Hinzufügen und bei der Konfiguration von Steuer-Abhängigkeiten, basierend auf den Projektanforderungen. Spring Boot wählt nach eigenem Ermessen die passenden Pakete zur Installation aus und setzt auch die Standardwerte, ohne dass ein nachträgliches manuelles Eingreifen erforderlich ist.

Man kann die Anforderungen des jeweiligen Projekts während des Initialisierungsprozesses definieren. Dabei wählt man zwischen mehreren Starter-Abhängigkeiten (den Spring Starters) die typische Anwendungsfälle abdecken. Man startet den Spring Boot Initializr (Das ist kein Rechtschreibfehler 😉 ), indem man ein einfaches Webformular ausfüllt. Alles erst einmal ohne zu programmieren und ohne Code.

Mit der Starter-Abhängigkeit „Spring Web“ kann man beispielsweise Spring-basierte Webanwendungen mit minimaler Konfiguration erstellen, indem man im Projekt alle erforderlichen Abhängigkeiten – wie den Apache Tomcat Webserver – hinzufügt. „Spring Security“ ist eine weitere vielfach eingesetzte Starter-Abhängigkeit, die automatisch Authentifizierungs- und Zugriffskontrollfunktionen zur Verfügung stelllt. Spring Boot enthält von Haus aus über 50 Spring-Starter, und viele weitere Starter von Drittanbietern sind ebenfalls verfügbar.

Eigenständige Anwendungen

Spring Boot hilft Entwicklern, Anwendungen zu erstellen, die einfach funktionieren. Insbesondere kann man damit eigenständige Anwendungen erstellen, die ohne einen externen Webserver auskommen, indem man einen Webserver wie Tomcat oder Netty während des Initialisierungsprozesses in der eigenen Anwendung einbettet. So kann man die Anwendung auf jeder Plattform starten, indem man einfach auf den Befehl „Ausführen“ klickt. Man kann aber auch auf diese Funktion verzichten, indem man dies in der Konfiguration deaktiviert.

Fazit

In der Praxis ist die Verwendung von Spring Boot durchaus zu empfehlen. Außer man hat vor, eine sehr spezielle Konfiguration zu implementieren. Man kann weiterhin das vielfach eingesetzte Annotationssystem von Spring Framework verwenden, mit dem man auf einfache Weise zusätzliche Abhängigkeiten (deren Abdeckung nicht von Spring Starters gewährleistet ist) in die Anwendung implementieren kann. Auch hat man weiterhin Zugriff auf alle Spring Framework-Funktionen, einschließlich der einfachen Ereignisverarbeitung, Prüfung und Bewertung, Datenbindung, Typumsetzung und der integrierten Sicherheits- und Testfunktionen. Kurz zusammengefasst – Wenn die Abdeckung des Projektumfangs lediglich ein Spring Starter gewährleistet, kann Spring Boot die Entwicklung signifikant rationalisieren.

Der Beitrag Spring Boot – Schnell und einfach Webanwendungen erstellen erschien zuerst auf CEOsBay.

Kurze Zeitreise

jQuery wurde im Jahr 2006 von John Resig entwickelt. Resig war ein Entwickler bei Mozilla und arbeitete an der Entwicklung von JavaScript–Frameworks. Er erkannte jedoch, dass die vorhandenen Frameworks zu umfangreich und schwerfällig waren und dass es schwierig war, plattformübergreifende Anwendungen zu entwickeln, die auf verschiedenen Browsern und Geräten funktionieren.

Um diese Herausforderung zu lösen, begann Resig damit, eine neue JavaScript-Bibliothek zu entwickeln, die schlanker und schneller als vorhandene Frameworks war. Er nannte diese Bibliothek „jQuery“ und veröffentlichte sie im Januar 2006.

Das Ziel war es, Entwicklern eine einfache und intuitive Methode zu bieten, um mit dem DOM (Document Object Model) zu arbeiten und interaktive Webanwendungen zu erstellen. jQuery sollte auch die Entwicklung von plattformübergreifenden Anwendungen erleichtern und dafür sorgen, dass Anwendungen auf allen gängigen Browsern gleich aussehen und funktionieren.

Dank seiner schlanken und schnellen Natur wurde jQuery schnell zu einer der am häufigsten verwendeten JavaScript-Bibliotheken in der Webentwicklung. Es hat die Art und Weise, wie Entwickler JavaScript-Code schreiben und Webanwendungen entwickeln, grundlegend verändert.

Heute ist es weiterhin eine der am häufigsten verwendeten JavaScript-Bibliotheken und wird von einer großen Entwicklergemeinschaft unterstützt, die ständig neue Funktionen und Erweiterungen entwickelt.

Funktionen von JQuery

Einer der Hauptvorteile von jQuery ist die Fähigkeit, das Schreiben von JavaScript-Code zu vereinfachen. Es bietet eine Vielzahl von Funktionen, die das Schreiben von Code für häufige Aufgaben wie DOM-Manipulationen, Event-Handling und AJAX-Anfragen erleichtern. Durch die Verwendung von jQuery können Entwickler schneller und effizienter arbeiten und so die Entwicklungsdauer ihrer Anwendungen verkürzen.

jQuery bietet auch eine Cross-Browser-Unterstützung, die es Entwicklern ermöglicht, plattformübergreifende Anwendungen zu entwickeln, ohne sich um Browser-Inkompatibilitäten kümmern zu müssen. Die Bibliothek stellt sicher, dass Anwendungen auf allen gängigen Browsern gleich aussehen und funktionieren.

Ein weiterer Vorteil von jQuery ist die umfangreiche Dokumentation und die große Entwickler-Community. Die Bibliothek ist seit vielen Jahren in der Webentwicklung im Einsatz und es gibt eine Vielzahl von Dokumentationen, Tutorials, Foren und anderen Ressourcen, die Entwicklern helfen, die Bibliothek zu nutzen. Die Community bietet auch eine Vielzahl von Plugins und Erweiterungen, die Entwickler verwenden können, um ihre Anwendungen zu erweitern.

jQuery bietet auch eine große Anzahl von Plugins und Erweiterungen, die Entwickler verwenden können, um ihre Anwendungen zu erweitern. Diese Plugins bieten zusätzliche Funktionen und ermöglichen es Entwicklern, die Bibliothek weiter anzupassen und zu erweitern.

Fazit

Alles in allem ist jQuery eine sehr nützliche und leistungsfähige JavaScript-Bibliothek, die es Entwicklern ermöglicht, Webanwendungen schneller und effizienter zu entwickeln. Es bietet eine Vielzahl von Funktionen und Unterstützung für plattformübergreifende Anwendungen. Durch die sehr umfangreiche Dokumentation und die große Entwickler-Community ist es auch relativ einfach zu erlernen bzw. am Ende des Tages zu verwenden. Wenn man Webanwendungen entwickelt, kann man es durchaus in Betracht ziehen, jQuery in die Tool-Box aufzunehmen.

Der Beitrag jQuery – Die schnelle und leichte Werkzeug Bibliothek erschien zuerst auf CEOsBay.

Es bietet eine Reihe von Funktionen und Tools, die es Entwicklern erleichtert, effektive und zuverlässige Tests für ihre JavaScript-Anwendungen zu schreiben. Zu den Funktionen von Jest gehören unter anderem:

Automatisierte Testausführung:

Jest führt Tests automatisch aus, wenn es Codeänderungen erkennt. Dies beschleunigt den Entwicklungsprozess und sorgt dafür, dass man häufiger bzw. effektiver Tests ausführen kann. Dies steigert am Ende des Tages die Qualität der Anwendungen grundsätzlich.

Snapshot-Tests:

Mit Jest können Entwickler Snapshot-Tests durchführen. Dadurch stellt man sicher, dass das Rendering der Komponenten oder Funktionen konsistent stattfindet. Dies kann auch dabei helfen, visuelle Fehler in der Benutzeroberfläche zu identifizieren und zu beheben.

Mocking:

Jest erleichtert das Erstellen von Mocks und Stubs für Abhängigkeiten, die man in den zu entwickelnden Anwendungen verwendet. Dies kann Entwicklern dabei helfen, ihre Tests zu isolieren und sicherzustellen, dass die Ausführung unabhängig voneinander stattfindet.

Codeabdeckung:

Jest bietet eine integrierte Codeabdeckungsfunktion. Dies ermöglicht den Entwicklern die Überprüfung, wie viel des Codes während der Testausführung abgedeckt ist. Dies kann helfen, Lücken in der Testabdeckung zu identifizieren und die Qualität der Anwendung insgesamt zu verbessern.

Parallele Testausführung:

Jest kann Tests parallel ausführen, was die Testdauer verkürzt, und die Gesamtgeschwindigkeit des Entwicklungsprozesses erhöht.

Fazit

Insgesamt ist Jest ein leistungsstarkes Testframework für JavaScript-Anwendungen, dass eine breite Palette von Funktionen bietet, um Entwicklern dabei zu helfen, effektive und zuverlässige Tests für ihre Anwendungen zu schreiben. Es ist eine wichtige Technologie für die Entwicklung moderner JavaScript-Anwendungen und viele Entwickler sowie Unternehmen weltweit nutzen es.

Der Beitrag Jest – Test-Framework für Testautomatisierung erschien zuerst auf CEOsBay.

Was ist DevOps?

DevOps ist ein Kofferwort, das aus den Begriffen „Development“ (Entwicklung) und „Operations“ (Betrieb) zusammengesetzt ist. Es beschreibt eine Philosophie, Kultur und Praxis, die darauf abzielt, die Zusammenarbeit und Kommunikation zwischen Entwicklern (Dev) und IT-Experten im Betrieb (Ops) zu verbessern. Der Ansatz ermöglicht es, Software schneller und mit höherer Qualität zu entwickeln, bereitzustellen und zu überwachen.

Grundprinzipien von DevOps

1. Zusammenarbeit: DevOps legt Wert auf eine enge Zusammenarbeit zwischen den verschiedenen Teams, um Wissensaustausch, gegenseitiges Verständnis und gemeinsame Verantwortung zu fördern.
2. Automatisierung: Die Automatisierung von Prozessen spielt eine zentrale Rolle in DevOps, um manuelle Aufgaben zu reduzieren und um Fehler zu minimieren.
3. Continuous Integration (CI): CI ist das automatisierte Zusammenführen von Codeänderungen aus unterschiedlichen Entwicklungsarbeiten. Dadurch kann man frühzeitig mögliche Konflikte oder Fehler erkennen und beheben.
4. Continuous Delivery (CD): Hierbei handelt es sich um die fortlaufende Bereitstellung von Software in verschiedenen Umgebungen (Test (Siehe TDD und BDD)), Staging, Produktion) zur Validierung und schnellen Bereitstellung von Updates.
5. Feedback und Lernen: DevOps ermutigt Teams, kontinuierlich Feedback zu sammeln und daraus zu lernen, um stetige Verbesserungen in der Softwareentwicklung zu erzielen.

Vorteile von DevOps

1. Schnellere Auslieferung bzw. Markteinführung: Durch die verbesserte Zusammenarbeit und Automatisierung von Prozessen kann man Software schneller entwickeln und ausliefern, was zu einem Wettbewerbsvorteil führt.
2. Höhere Qualität: Man kann Fehler frühzeitig entdecken und beheben, wodurch man die Qualität der Software verbessert.
3. Reduzierte Kosten: Durch effizientere Prozesse und Automatisierung kann man die Kosten senken und Ressourcen optimal nutzen.
4. Erhöhte Flexibilität: Die enge Zusammenarbeit und ständige Verbesserung der Prozesse ermöglichen es Unternehmen, schneller auf Veränderungen zu reagieren und Innovationen voranzutreiben.

Nachteile von DevOps

Obwohl es zahlreiche Vorteile für Unternehmen und Entwicklerteams bietet, gibt es auch einige Nachteile, die man bei der Einführung und Umsetzung dieses Ansatzes berücksichtigen sollte:

1. Kulturelle Herausforderungen: Eine der größten Herausforderungen bei der Implementierung von DevOps ist der Wandel der Unternehmenskultur. Die Zusammenarbeit zwischen Entwicklern und IT-Experten im Betrieb erfordert eine Änderung von Denkmustern und Arbeitsweisen, was nicht immer einfach ist.
2. Anfangsinvestition: Um es erfolgreich umzusetzen, müssen Unternehmen oft in neue Tools, Technologien und Schulungen investieren. Dies kann insbesondere für kleinere Unternehmen eine finanzielle Belastung darstellen.
3. Komplexität: Die Einführung von DevOps kann zu erhöhter Komplexität führen, da man zusätzliche Prozesse und Tools in den Entwicklungs- und Betriebsablauf integrieren muss. Dies erfordert eine umfangreiche Planung und Koordination, um effizient und erfolgreich zu sein.
4. Widerstand im Team: Nicht alle Teammitglieder sind von Anfang an von den Vorteilen von DevOps überzeugt. Einige können skeptisch sein oder den Wandel ablehnen, was zu Konflikten und Spannungen innerhalb des Teams führen kann.
5. Sicherheitsrisiken: Trotz des DevSecOps-Ansatzes, bei dem man Sicherheit in den Entwicklungsprozess integriert, kann die Einführung von DevOps zu zusätzlichen Sicherheitsrisiken führen. Zum Beispiel kann die automatisierte Bereitstellung von Code unbeabsichtigte Sicherheitslücken oder Fehler aufweisen, die Angreifern ausnutzen könnten.
6. Kontinuierliche Anpassung: Da DevOps ein agiles Vorgehen erfordert, müssen sich Teams ständig an neue Technologien, Methoden und Prozesse anpassen. Dies kann anstrengend und zeitaufwändig sein und dazu führen, dass sich einige Mitarbeiter überfordert fühlen.

Um diese Nachteile zu minimieren, ist es wichtig, bei der Einführung von DevOps eine gut durchdachte Strategie zu verfolgen, die alle Aspekte des Prozesses berücksichtigt. Offene Kommunikation, Schulungen und das Sammeln von Feedback sind entscheidend, um ein erfolgreiches DevOps-Umfeld zu schaffen und die möglichen Nachteile zu bewältigen.

Best Practices für DevOps

1. Kultur der Zusammenarbeit fördern: Es ist entscheidend, ein Arbeitsumfeld zu schaffen, in dem Entwickler und IT-Experten im Betrieb offen kommunizieren und zusammenarbeiten können.
2. Tools und Technologien nutzen: Für eine erfolgreiche Implementierung von DevOps ist es wichtig, geeignete Tools und Technologien einzusetzen, um Prozesse zu automatisieren und die Zusammenarbeit zu erleichtern. Dazu zählen CI/CD-Tools wie Jenkins oder GitLab bzw. GitHub, Container-Technologien wie Docker und Kubernetes sowie Monitoring- und Logging-Tools wie Grafana und ELK Stack.
3. Infrastruktur als Code (IaC) einsetzen: Mit IaC können Entwickler und Betriebsteams die Infrastruktur ähnlich wie bei Softwareanwendungen entwickeln, verwalten und versionieren. Dadurch kann man die Konsistenz und Reproduzierbarkeit der Umgebungen gewährleisten. Beispiele für IaC-Tools sind Terraform, Ansible und Chef.
4. Monitoring und Feedback: Um kontinuierlich zu lernen und Verbesserungen voranzutreiben, sollten Unternehmen umfangreiches Monitoring einsetzen, um Probleme frühzeitig zu erkennen und Feedback in den Entwicklungsprozess einfließen zu lassen.
5. Sicherheit integrieren: Man sollte auch den Aspekt der Sicherheit berücksichtigen, indem Entwickler und Betriebsteams eng mit Sicherheitsexperten zusammenarbeiten. Der Ansatz „DevSecOps“ betont die Integration von Sicherheitsmaßnahmen in den gesamten Softwarelebenszyklus.
6. Experimentieren und Lernen: Man sollte DevOps-Teams immer wieder ermutigen, kontinuierlich neue Technologien, Prozesse und Methoden auszuprobieren, um aus Fehlern zu lernen und Innovationen voranzutreiben.

Fazit

DevOps ist eine transformative Strategie, die in der modernen Softwareentwicklung unerlässlich geworden ist. Durch die Zusammenarbeit zwischen Entwicklern und IT-Experten im Betrieb, die Automatisierung von Prozessen und den kontinuierlichen Feedback- und Lernprozess wird die Softwareentwicklung beschleunigt, die Qualität verbessert und die Flexibilität erhöht.

Die Einführung von DevOps erfordert jedoch Zeit und Engagement, um sowohl die Kultur als auch die notwendigen Technologien und Prozesse in einem Unternehmen zu etablieren. Eine erfolgreiche Implementierung von DevOps setzt voraus, dass Unternehmen bereit sind, sich kontinuierlich weiterzuentwickeln und ihre Teams mit den notwendigen Ressourcen und dem Wissen auszustatten. Der Einsatz von Best Practices und eine fortwährende Verbesserung der Prozesse sind Schlüsselfaktoren für den Erfolg von DevOps in der Softwareentwicklung.

Der Beitrag DevOps – Entwickeln, bereitstellen und verbessern erschien zuerst auf CEOsBay.

Eine wirklich kurze Zeitreise

Die Extensible Markup Language wurde vom World Wide Web Consortium (W3C) am 10. Februar 1998 veröffentlicht. Die aktuelle Fassung ist die fünfte Ausgabe vom 26. November 2008. Alle bisherigen und aktuellen Publikationen kann man hier einsehen.

Was ist XML nun wirklich und was tut es?

Es ist eine Metasprache, auf deren Basis durch strukturelle und inhaltliche Einschränkungen anwendungsspezifische Sprachen definiert werden. Diese Einschränkungen werden entweder durch eine Document Type Definition (DTD) oder durch ein XML Schema ausgedrückt. Beispiele für XML-Sprachen sind: RSS, MathML, GraphML, XHTML, XAML, Scalable Vector Graphics (SVG), GPX, aber auch das XML-Schema selbst. Auf diese Sprachen gehe ich in zukünftigen Sprachen ein. Besonders SVG hat einen Großteil meiner persönlichen Entwicklung geprägt.

Die Standardzeichenkodierung eines XML-Dokumentes ist UTF-8. XML-bearbeitende Systeme müssen die Kodierungen UTF-8 und UTF-16 beherrschen. XML-Dokumente, die UTF-8 oder UTF-16 verwenden, können in allen Texteditoren, die diese Kodierungen unterstützen, angezeigt und bearbeitet werden. Damit sind so ziemlich alle „Browser“ gemeint 😉

Wenn das XML-Dokument Binärdaten enthalten soll, müssen diese Daten zu Text konvertiert bzw. umkodiert werden. Dazu kann z. B. die Base64-Kodierung verwendet werden.

Das Element

Die essenzielle Struktureinheit eines XML-Dokumentes ist das Element. Elemente können Text wie auch weitere Elemente als Inhalt enthalten. Elemente bilden die Knoten des Strukturbaumes eines XML-Dokumentes. Der Name eines Elementes kann in Dokumenten ohne Dokumenttypdefinition (DTD) frei gewählt werden. In XML-Dokumenten mit DTD muss der Name eines Elementes in der DTD deklariert sein und das Element muss sich in einer zugelassenen Position innerhalb des Strukturbaumes gemäß DTD befinden. In der DTD wird u. a. der mögliche Inhalt eines jeden Elementes definiert. Elemente sind die Träger der Information in einem XML-Dokument.

Tag

Für die Auszeichnung von Elementen werden Tags verwendet. Auf den ersten Blick sehen XML-Tags fast wie HTML-Tags aus. Start-Tags beginnen mit < und End-Tags mit </. Bei beiden folgt anschließend der Name des Elements, und sie werden beide durch > geschlossen. Anders als bei den HTML-Tags können Sie jedoch neue Tags erzeugen. Um eine Person zu beschreiben, benutzt man die Tags <person> und </person>. Um ein Tier zu beschreiben, verwendet man die Tags <tier> und </tier>. Die Namen der Tags spiegeln im Allgemeinen die Art des Inhalts innerhalb des Elements wider und nicht die Art und Weise, wie der Inhalt formatiert wird.

Wohlgeformtheit

Ein XML-Dokument ist „wohlgeformt“ (well-formed), wenn es alle Regeln einhält.

Die Regeln

• Das Dokument besitzt genau ein Wurzelelement. Als Wurzelelement wird dabei das jeweils äußerste Element bezeichnet, z. B. <html> in XHTML.
• Alle Elemente mit Inhalt besitzen einen Start- und einen Endtag (z. B. <eintrag>Eintrag 1</eintrag>). Elemente ohne Inhalt können mit einem Leertag gekennzeichnet werden (z. B. <eintrag />).
• Die Start- und Endtags sind ebenentreu-paarig verschachtelt. Dies bedeutet, dass alle Elemente geschlossen sind, bevor die End-Auszeichner des entsprechenden Elternelements oder die Beginn-Auszeichner eines Geschwisterelements erscheinen.
• Ein Element darf nicht mehrere Attribute mit demselben Namen besitzen.
• Attributwerte müssen in Anführungszeichen stehen („…“ oder ‚…‘).
• Die Start- und Endtags sind Case sensitive, also beachten die Groß- und Kleinschreibung (z. B. <eintrag></Eintrag> ist ungültig).

Gültigkeit (Validität)

Verwendet man es für den Datenaustausch, ist es von Vorteil, wenn das Format mittels einer Grammatik (z. B. einer Dokumenttypdefinition oder eines XML-Schemas) definiert ist. Der Standard definiert ein XML-Dokument als gültig (oder englisch valid), wenn es wohlgeformt ist, den Verweis auf eine Grammatik enthält und das durch die Grammatik beschriebene Format einhält.

Parser

Programme oder Programmteile, die XML-Daten auslesen, interpretieren und ggf. auf Gültigkeit prüfen, nennt man XML-Parser. Prüft der Parser die Gültigkeit, so ist er ein validierender Parser. Darauf gehe ich aber in einem zukünftigen Beitrag genauer ein.

Wie sieht die Extensible Markup Language eigentlich aus?

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<verzeichnis>
    <titel>Städteverzeichnis</titel>
    <eintrag>
        <stichwort>München</stichwort>
        <eintragstext>München ist der Sitz von ...</eintragstext>
    </eintrag>
    <eintrag>
        <stichwort>Donauwörth</stichwort>
        <eintragstext>Donauwörth ist eine Stadt, die ...</eintragstext>
    </eintrag>
</verzeichnis>

XML-Dokumente besitzen einen physischen und einen logischen Aufbau.

Der physische Aufbau

• Die Dokument-Entität (Document entity) enthält das Hauptdokument.
• Weitere mögliche Entitäten sind über Entitätenreferenzen (&name; für das Dokument bzw. %name; für die Dokumenttypdefinition) eingebundene Zeichenketten, eventuell auch ganze Dateien, sowie Referenzen auf Zeichenentitäten zur Einbindung einzelner Zeichen, die über ihre Nummer referenziert wurden (&#Dezimalzahl; oder &#xHexadezimalzahl;).
• Eine XML-Deklaration wird verwendet, um die Version, Zeichenkodierung und eine mögliche Verarbeitbarkeit ohne DTD zu spezifizieren.
• Eine DTD wird verwendet, um Entitäten sowie den erlaubten logischen Aufbau zu spezifizieren. Die Verwendung einer DTD kann in der Deklaration abgewählt werden.

Der logische Aufbau

Der logische Aufbau entspricht einer Baumstruktur und ist damit hierarchisch organisiert. Es gibt folgende Baumknoten:

• Elemente, deren physische Auszeichnung mittels eines passenden Paars aus Starttag <Tagname> und End-Tag </Tagname> oder eines Leertags <Tagname/> erfolgen kann.
• Attribute als bei einem Starttag oder Leertag geschriebene zusätzliche Eigenschaften der Elemente in der Syntax Attributname=Attributwert.
• Verarbeitungsanweisungen <?Zielname Daten?> (engl. Processing Instructions).
• Kommentare <!– Kommentar-Text –>.
• Text, der als normale Zeichendaten oder in Form eines CDATA-Abschnittes <![CDATA[ beliebiger Text]]> auftreten kann.

Ein XML-Dokument muss genau ein Element auf der obersten Ebene enthalten. Unterhalb dieses Dokumentelements können weitere Elemente und Texte verschachtelt werden.

Was ist DTD

Wie vorher kurz ausgeschrieben und angeschnitten, handelt es sich dabei um die Dokumenttypdefinition und beschreibt die Struktur sowie Grammatik von Dokumenten. Sie ist Systembestandteil von XML und per Standard aktiviert.

Werden Dokumente mit Bezug zu einer externen Dokumenttypdefinition oder mit einer integrierten Dokumenttypdefinition erstellt, prüft der Parser das Dokument bereits beim Öffnen (Lesen). Ein Dokument auf Basis einer Dokumenttypdefinition ist stets ein valides Dokument. Die Übereinstimmung des Dokumentinhaltes mit den Regeln der Dokumenttypdefinition steht im Vordergrund. Die technische Lesbarkeit, also auch das Lesen von nicht validen Dokumenten ist nachrangig. Das ist für Volltextdokumente (erzählende Dokumente, engl. narrative documents) vorgesehen und der Haupteinsatzzweck.

Dokumente ohne DTD sind eher für den beliebigen Datenaustausch geeignet. Der Parser prüft diese Dokumente nur nach den Regeln der Wohlgeformtheit. Die technische Lesbarkeit steht hier an erster Stelle. Das Prüfen und Auslesen der eigentlichen Informationen wird mit nachgelagerten Prozessen realisiert.

Lesbarkeit

Wie zu Beginn erwähnt, können alle Webbrowser wie Apple Safari, Google Chrome, Microsoft Edge, Mozilla Firefox, Opera usw. XML-Dokumente mit Hilfe des eingebauten Parsers direkt visualisieren. Dadurch werden keine zusätzlichen PlugIns oder der Gleichen benötigt.

Klassifizierung von XML-Dokumenten

XML-Dokumente lassen sich anhand ihrer Bestimmung und ihres Strukturierungsgrades in dokumentzentrierte und datenzentrierte Dokumente unterteilen. Die Grenze zwischen diesen Dokumentenarten ist fließend. Mischformen können als semistrukturiert bezeichnet werden.

Dokumentzentriert

Das Dokument ist an ein Textdokument angelehnt, dass für den menschlichen Leser größtenteils auch ohne die zusätzliche Metainformation verständlich ist. XML-Elemente werden hauptsächlich zur semantischen Markierung von Passagen des Dokuments genutzt. 

Das Dokument ist nur schwach strukturiert. Aufgrund der schwachen Strukturierung ist eine maschinelle Verarbeitung schwierig.

Datenzentriert

Das Dokument ist hauptsächlich für die maschinelle Verarbeitung bestimmt. Es folgt einem Schema, das Entitäten eines Datenmodells beschreibt und definiert, in welcher Beziehung die Entitäten zueinanderstehen und welche Attribute die Entitäten haben. Das Dokument ist somit stark strukturiert und für den unmittelbaren menschlichen Gebrauch weniger geeignet.

Semistrukturiert

Semistrukturierte Dokumente stellen eine Art Mischform dar, die stärker strukturiert ist als dokumentzentrierte Dokumente, aber schwächer als datenzentrierte Dokumente.

Es ist typisch für datenzentrierte XML-Dokumente, dass Elemente entweder Elementinhalte oder Textinhalte haben. Der sogenannte gemischte Inhalt (Mixed Content), bei dem Elemente sowohl Text als auch Childs (Kind-Elemente) enthalten, ist für die anderen XML-Dokumente typisch.

Verarbeitungskriterien der Extensible Markup Language

Grundsätzlich sind drei Aspekte beim Zugriff auf ein XML-Dokument von Bedeutung:

1. Wie erfolgt der Zugriff auf die XML-Datei: sequenziell oder wahlfrei?
2. Wie ist der Ablauf beim Zugriff auf die Daten gestaltet: „Push“ oder „Pull“? (Push bedeutet, dass die Ablaufkontrolle des Programms beim Parser liegt. Pull bedeutet, dass die Ablaufkontrolle im Code, der den Parser aufruft, implementiert ist.)
3. Wie erfolgt das Baumstrukturmanagement der XML-Daten: hierarchisch oder verschachtelt?

Programmgesteuerter Zugriff auf XML-Dokumente

Das Einlesen von XML-Dokumenten erfolgt auf unterster Ebene über eine spezielle Programmkomponente, einem XML-Prozessor, auch XML-Parser genannt. Er stellt eine Programmierschnittstelle (API) zur Verfügung, über die die Anwendung auf das XML-Dokument zugreift. Ich habe zwar in einem vorherigen Beitrag über die REST API geschrieben, doch werde ich definitiv die Programmierschnittstelle explizit nochmals ein einem Beitrag thematisieren.

Die XML-Prozessoren unterstützen dabei drei grundlegende Verarbeitungsmodelle

1. DOM: Ein DOM-API repräsentiert ein XML-Dokument als Baumstruktur und gewährt wahlfreien Zugriff auf die einzelnen Bestandteile der Baumstruktur. DOM erlaubt außer dem Lesen von den Dokumenten auch die Manipulation der Baumstruktur und das Zurückschreiben der Baumstruktur in ein XML-Dokument. Aus diesem Grund ist DOM sehr speicherintensiv.
2. SAX: Ein SAX-API repräsentiert ein XML-Dokument als sequentiellen Datenstrom und ruft für im Standard definierte Ereignisse vorgegebene Rückruffunktionen (callback function) auf. Eine Anwendung, die SAX nutzt, kann eigene Unterprogramme als Rückruffunktionen registrieren und auf diese Weise die Daten auswerten.
3. Pull-API: Eine XML-Pull-API verarbeitet Daten sequenziell und bietet sowohl ereignisbasierte Verarbeitung als auch einen Iterator an. Es ist hoch speichereffizient und ggf. leichter zu programmieren als das SAX-API, da die Ablaufkontrolle beim Programm und nicht beim Parser liegt.

Weitere Verarbeitungsmodelle sind das Data-Binding, welches die XML-Daten als Datenstruktur direkt für einen Programmzugriff bereitstellt. Die XML-Daten werden per Unmarshalling (Dies ist der Prozess der Umwandlung einer Art von Darstellung auf niedrigerer Ebene, oft ein „Drahtformat“, in eine Struktur auf höherer Ebene (Objekt).) direkt in z. B. Objekte gewandelt. Und die Nicht-extrahierende-XML-API, bei der die Daten auf Byte-Ebene sehr effizient verarbeitet sind.

Oftmals greift der Anwendungscode nicht direkt auf die Parser-API zu. Stattdessen wird es weiter gekapselt, so dass der Anwendungscode mit nativen Objekten / Datenstrukturen arbeitet, welche sich auf darauf abstützen. Beispiele für solche Zugriffsschichten sind JAXB in Java, der Data Binding Wizard in Delphi oder das XML Schema Definition Toolkit in .Net. Die Umwandlung von Objekten in die Extensible Markup Language ist üblicherweise bidirektional möglich. Diese Umwandlung bezeichnet man als Serialisierung oder Marshalling.

Transformation und Darstellung von XML-Dokumenten

Ein XML-Dokument kann mittels geeigneter Transformationssprachen wie XSLT oder DSSSL in ein anderes Dokument transformiert werden. Oftmals dient die Transformation zur Überführung eines Dokuments aus einer Extensible Markup Language in eine andere Extensible Markup Language, beispielsweise zur Transformation nach XHTML, um das Dokument in einem Webbrowser anzuzeigen.

Warum XML?

Unterstützung von und bei Transaktionen

Wenn ein Unternehmen eine Ware oder Dienstleistung an ein anderes Unternehmen verkauft, müssen die beiden Unternehmen Informationen wie Kosten, Spezifikationen und Lieferpläne austauschen. Man kann damit alle erforderlichen Informationen elektronisch teilen und komplexe Geschäfte automatisch abschließen, ohne dass ein menschliches Eingreifen erforderlich ist.

Aufrechterhaltung der Datenintegrität

Man kann damit Daten zusammen mit der Beschreibung der Daten übertragen und so den Verlust der Datenintegrität verhindern. Folglich kann man so die Datengenauigkeit überprüfen, automatische Anpassungen der Datenpräsentation für verschiedene Benutzer vornehmen und Daten konsistent über mehrere Plattformen hinweg speichern 

Sucheffizienz verbessern

Computerprogramme wie Suchmaschinen können die Dateien damit effizienter und präziser sortieren und kategorisieren als andere Arten von Dokumenten. Beispielsweise kann das Wort mark (markieren) entweder ein Substantiv oder ein Verb sein. Basierend auf XML-Tags können Suchmaschinen mark für relevante Suchergebnisse genau kategorisieren. Somit hilft es, die natürliche Sprache für Maschinen effizienter interpretierbar zu machen.

Flexible Anwendungen entwerfen

Man kann damit auch das eigene Anwendungsdesign bequem aktualisieren oder ändern. Viele Technologien, insbesondere neuere Technologien, verfügen dafür über eine integrierte Schnittstelle bzw. Unterstützung. So kann man automatisch Datendateien lesen und verarbeiten, sodass die Änderungen stattfinden können, ohne gleich die gesamte Datenbank neu formatieren zu müssen.

Der Beitrag XML – Effiziente Datenstrukturierung erschien zuerst auf CEOsBay.