How-To

JavaScript-Fehler beheben: Den Bugs auf der Spur

Seite 2 / 3

Breakpoints

Vielen Entwicklern erscheint es zunächst reizvoll, ihren Quellcode mit unzähligen Konsolen-Ausgaben zu bestücken, mit denen sie Variablen, Events oder Conditions nachvollziehen können. Doch was wäre, wenn sie die Ausführung des Quellcodes an einem bestimmten Zeitpunkt pausieren lassen und von da an schrittweise untersuchen könnten? Wie wäre es mit der Manipulation von Variablen und Parametern? So genannte „Breakpoints“ machen dies möglich. Durch die Platzierung eines „debugger statement“ legt der Browser an entsprechender Stelle eine Pause ein und liefert nebenbei den für das Debuggen nützlichen Call-Stack.

Mittels debugger statement die Ausführung anhalten

debugger;

Listing 5

Um ein Vielfaches mächtiger ist die Steuerung innerhalb der Developer-Tools. Neben den statischen Breakpoints, die an eine bestimmte Code-Zeile gebunden sind, gibt es hier auch solche, die folgende Ereignisse im Browser auslösen:

  • Veränderung eines DOM-Knoten
  • Auslösen eines XHR
  • Auslösen eines Event Listener
  • Werfen einer Uncaught Exception

Auf diese Weise können Entwickler JavaScript von Drittanbietern ohne Vorkenntnisse untersuchen und anhand von ausgelösten Ereignissen zum Quellcode springen.

Sourcemaps

Wer komprimierten Quellcode vernünftig debuggen will, muss Sourcemaps generieren. Diese stellen eine Verknüpfung zum ursprünglichen Quellcode her und zeigen beispielsweise das zu JavaScript kompilierte CoffeeScript direkt im Browser an.

Debugging externer Geräte

Zu den großen Herausforderungen in Zeiten des Responsive Designs gehören vor allem externe Geräte. Zum Beispiel gilt die mobile Browser-Version von Safari nicht grundlos als neuer Internet Explorer: Apple hinkt seit Jahren in der Entwicklung hinterher und bemüht sich nicht gerade, die Bedürfnisse der Community zu erfüllen. Entwickler, die eine mangelhaft implementierte JavaScript API oder nicht funktionierende Touch-Gesten auf einem externen Gerät debuggen wollen, können sich mit Hilfe von mindestens drei Ansätzen auf die Fehlersuche begeben: dem USB-, dem WLAN- und dem Browser-Remote-Debugging.

Chrome gehört zu den Vorreitern im Bereich USB-Remote-Debugging. Über eine spezielle URL können Entwickler sich die mit dem PC verbundenen Android-Geräte anzeigen lassen. (Screenshot: Google)

USB-Remote-Debugging

Der Klassiker hierbei ist das USB-Remote-Debugging, bei dem ein USB-Kabel den Test-PC mit dem externen Gerät verbindet. In den Entwickleroptionen von Android befindet sich ein Schalter, um es zu aktivieren. Chrome, Firefox und Safari bieten dafür unterschiedliche Optionen:

  • Chrome: Der Browser gehörte zu den Vorreitern dieser Methode. Über die URL chrome://inspect können sich Entwickler die mit dem PC verbundenen Android-Geräte über den Browser anzeigen lassen und gegebenenfalls konfigurieren. Dabei ist es unerheblich, um welche Art von Gerät es sich dabei handelt, solange der mobile Browser Chrome oder eine App mit Hilfe der WebView offen sind.
  • Firefox: Einige Zeit später kam die WebIDE für Firefox heraus, die ähnliche Möglichkeiten für die mobile Version von Firefox anbietet. Wie bei den älteren Chrome-Versionen müssen Entwickler die Erlaubnis für das USB-Debugging zunächst jedoch in den erweiterten Einstellungen des mobilen Firefox aktivieren. Dann zeigt der Browser Geräte, die verfügbar sind, in der WebIDE an. Die Developer-Version des Firefox enthält außerdem das experimentelle Add-on „Valence“ (Firefox Tools Adapter), mit dem sich auch
    Nicht-Gecko-Browser ansprechen lassen. Die Autoren der Dokumentation
    berichten von erfolgreichen Tests gegen die mobile Browser-Version von
    Chrome und Safari sowie gegen Apps, die auf iOS mit einer WebView laufen.
  • Safari: Die mobile Browser-Version bringt ebenfalls das
    Handwerkszeug zum USB-Debugging mit. Nachdem man die Developer-Tools auf
    dem Desktop und den Web-Inspector auf dem mobilen Safari aktiviert hat,
    erscheint im Menü „Entwickler“ das externe Gerät. Selbstverständlich braucht man dazu einen
    Apple-Computer.

In Firefox läuft das USB-Remote-Debbuging über die WebIDE, die ähnliche Funktionen wie Chrome bietet. (Screenshot: Google)

WLAN-Remote-Debugging

Zuerst die schlechte Nachricht: Debugging über das lokale Netzwerk
ist mit Chrome nur im Terminal zu bewerkstelligen. Vermutlich verliert
die offizielle Dokumentation deshalb auch kein Wort darüber. Es gibt
also keine offizielle Anleitung, die unter anderem Root-Zugriff
benötigt.

Die gute Nachricht: Firefox macht es besser, denn in der WebIDE ist Debugging über das lokale Netzwerk schon seit einigen Releases fest verbaut und kinderleicht. Hierfür müssen Entwickler in den erweiterten Einstellungen des mobilen Firefox nur die Erlaubnis für WLAN-Debugging aktivieren und schon erscheint das Gerät in der WebIDE. Um die Verbindung mit dem externen Gerät zu bestätigen, muss man eine Client-Identifikation über einen QR-Code-Scanner bestätigen.

Bitte beachte unsere Community-Richtlinien

Wir freuen uns über kontroverse Diskussionen, die gerne auch mal hitzig geführt werden dürfen. Beleidigende, grob anstößige, rassistische und strafrechtlich relevante Äußerungen und Beiträge tolerieren wir nicht. Bitte achte darauf, dass du keine Texte veröffentlichst, für die du keine ausdrückliche Erlaubnis des Urhebers hast. Ebenfalls nicht erlaubt ist der Missbrauch der Webangebote unter t3n.de als Werbeplattform. Die Nennung von Produktnamen, Herstellern, Dienstleistern und Websites ist nur dann zulässig, wenn damit nicht vorrangig der Zweck der Werbung verfolgt wird. Wir behalten uns vor, Beiträge, die diese Regeln verletzen, zu löschen und Accounts zeitweilig oder auf Dauer zu sperren.

Trotz all dieser notwendigen Regeln: Diskutiere kontrovers, sage anderen deine Meinung, trage mit weiterführenden Informationen zum Wissensaustausch bei, aber bleibe dabei fair und respektiere die Meinung anderer. Wir wünschen Dir viel Spaß mit den Webangeboten von t3n und freuen uns auf spannende Beiträge.

Dein t3n-Team

2 Kommentare
Hans
Hans

Langer Artikel und trotzdem nicht schön zu lesen. Alle Themen werden nur angerissen, meist nur mit ein oder zwei Sätze. Leider fehlen weiterführende Links zu den einzelnen Themen.
Spannendes Thema und trotzdem habe ich nichts gelernt. Sehr Schade.

Antworten
Henry Ruhs

Danke für das Feedback.

Im Wesentlichen hast du es auf den Punkt gebracht und ich kann deine Kritik absolut nachvollziehen. Mir ist die Quadratur des Kreises offenbar nicht gelungen, denn ich wollte auf keine Themen verzichten, obwohl mir im Print-Magazin nur drei Seiten zur Verfügung standen. Am Ende wurde auch noch sehr viel gekürzt und von der Redaktion umgeschrieben :-)

Um das zu kompensieren, hatte ich mir die Mühe gemacht dem Leser ein Demo auf GitHub an die Hand zu geben, wo man Schritt für Schritt nachvollziehen kann.

https://github.com/redaxmedia/javascript-testing-stack

Die weiterführenden Links werde ich an die Redaktion übermitteln.

Antworten

Melde dich mit deinem t3n Account an oder fülle die unteren Felder aus.

Bitte schalte deinen Adblocker für t3n.de aus!

Hey du! Schön, dass du hier bist. 😊

Bitte schalte deinen Adblocker für t3n.de aus, um diesen Artikel zu lesen.

Wir sind ein unabhängiger Publisher mit einem Team bestehend aus 65 fantastischen Menschen, aber ohne riesigen Konzern im Rücken. Banner und ähnliche Werbemittel sind für unsere Finanzierung sehr wichtig.

Danke für deine Unterstützung.

Digitales High Five,
Stephan Dörner (Chefredakteur t3n.de) & das gesamte t3n-Team

Anleitung zur Deaktivierung