Exploring JavaScript - OOP, Ajax und Web 2.0
Buchausgabe: 24,90€
Download-Version: 21,20€
(Preis inkl. Mwst. )
| Autor(en): | Markus Nix, Christian Gross, Jörg Schaible, Christian Wenz, Sebastian Werner |
| Verlag: | entwickler.press |
| Version: | 1. Auflage, 2007 |
| Umfang: | 165 Seiten |
| Format: | PDF: 2,55MB |
| Gewicht: | 240 g |
| ISBN: | 393908428X |
| Bestell-Nr.: | 93908428P |
| Artikeltyp: | E-Book |
Der Leser erhält Wissen aus erster Hand. Namhafte, in der JavaScript-Community verwurzelte JavaScript-Profis erlauben dem Leser Einblick in ihre Projekte. Arne Blankerts widmet sich dem X in Ajax, Jörg Schaible stellt JsUnit vor und Markus Nix enthüllt unbekannte Aspekte von JavaScript.
Die Autoren
Markus Nix hat ein illustres Autorenteam um sich geschart. Christian Gross und Arne Blankerts sind anerkannte Autoren und Sprecher auf Konferenzen und Jörg Schaible ist Vater von JsUnit.
Leseprobe:
2 Unit-Tests mit JavaScript (S. 51)
Von Jörg Schaible
2.1 Motivation
Als JavaScript Ende 1995 im Netscape Navigator 2.0 eingeführt wurde, dachte noch keiner an die Entwicklung von kompletten Anwendungen in dieser Sprache. Größere Entwicklungen waren interessanterweise zuerst im Serverbereich zu finden, wo mit Hilfe von JavaScript Server Pages die Entwicklung von dynamischen Webseiten den Fähigkeiten der Webdesigner entgegenkommen sollte (Netscape iPlanet, BroadVision 1-to-1, Day Communiqué, IXOS Obtree). Die Standardisierung von JavaScript, die Weiterentwicklung der Browser (speziell auch bezüglich Kompatibilität und Konformität) und die Verfügbarkeit von schnellen Internetverbindungen haben die Situation grundlegend verändert.
Aktuelle DOM-Implementierungen erlauben die Manipulation des dargestellten Dokuments on-the-fly. Zusätzlich ist in den wichtigsten Browsern ein Datenaustausch über XML möglich, sodass sowohl der Datenaustausch mit dem Server als auch die Darstellung der Daten optimiert werden kann. Diese Funktionalitäten werden clientseitig in JavaScript-Bibliotheken gekapselt, welche einen beträchtlichen Umfang annehmen können.
Schon lange sind im Internet auf den einschlägigen Seiten viele einzelne Funktionen als so genannte Scriptlets für einzelne Effekte erhältlich. Aktuell geht der Trend zu größeren JavaScript-Bibliotheken, die dem Programmierer die unterschiedlichsten Funktionalitäten aus einer Hand liefern. Diese Bibliotheken präsentieren sich nicht mehr als eine Sammlung loser Funktionen, sondern verwenden intensiv die objektorientierten Möglichkeiten von JavaScript. Spätestens hier wird klar, dass solche größeren Script-Bibliotheken mit den gleichen Problemen kämpfen wie jedes andere Software-Projekt.
Je größer die Anzahl der Schichten, je mehr Funktionen und Objekte im Einsatz sind, desto schwieriger wird es, die Funktionalität sicherzustellen. Insbesondere bei einer Script-basierten Programmiersprache, bei der ein Schreibfehler in einem Variablennamen nicht unbedingt direkt zu einem Fehler führt, sondern unter Umständen zu einer ungewollten Deklaration einer neuen Variablen, muss sich jeder beteiligte Entwickler ernsthafte Gedanken über die Erstellung und Durchführung von Testfällen machen.
2.1.1 Testbarkeit
Wenn wir eine Anwendung schreiben, definieren wir logische Schichten der Funktionalität und schreiben Komponenten, die aufeinander aufbauen. Ganz am Ende der Entwicklung steht ein letzter Funktionstest, der bei einem Auftrag eine Abnahme durch den Kunden bedeutet. Umfasst die Anwendung eine gewisse Größe, sind oft mehrere Entwickler mit der Umsetzung der Anwendung beschäftigt. Diese können am besten arbeiten, wenn ihre Komponenten so weit wie möglich gekapselt sind und nur über definierte Schnittstellen miteinander kommunizieren.
Die „natürliche" Hierarchie wird durch ein Abhängigkeitsverhältnis zwischen den einzelnen Komponenten beschrieben und funktioniert analog zu den einzelnen logischen Schichten der Anwendung. Es gilt zyklische Beziehungen zwischen ihnen zu vermeiden, um einen Funktionsumfang zu definieren, die Wartbarkeit zu erhöhen, Tests zu vereinfachen und die Wiederverwendung der Komponenten zu erleichtern. Insbesondere die Testbarkeit des Codes darf nicht mit dem Testen selbst verwechselt werden. Das sind zwei unterschiedliche und sogar weitgehend unabhängige Aspekte der Qualitätssicherung.
Das kontinuierliche Testen und der erfolgreiche Endtest signalisiert dem Anwender, dass das Endprodukt den geforderten Funktionen entspricht und beschreibt einen Zustand des Produkts. Die Testbarkeit hingegen ist Teil einer effektiven Strategie, die die über eine Schnittstelle angebotene Funktionalität verifizieren soll.
Deswegen erfüllt qualitativ hochwertiger Code folgende Eigenschaften:
Keine zyklischen Abhängigkeiten zwischen den Komponenten
Entkoppelung von Funktionalität über Schnittstellen
Trennung von Daten und Diensten
Der besondere Tipp
Denken Sie nicht an einen blauen Elefanten!
Anhand verblüffender Experimente und einfacher Übungen lernen Sie, wie unsere Umwelt die Gedanken und die Gedanken unsere Umwelt beeinflussen.
Früher: 12,00€
bei uns nur: 4,99€

