Was nicht ganz so bekannt ist, man kann sogar über den Firebug aus JScript heraus Debug-Logs generieren.

Beispielsweise gibt…

console.log('Hallo Welt!');

…genau diesen Text in der Konsole aus.

Das kann man noch etwas verfeinern, denn schließlich unterscheidet man Infos, Warnings, Errors und Debugs!

console.debug('Debug');
console.info('Information');
console.warn('Warnung');
console.error('Fehler');

Und auch die Ausgabe von Variablen kommt nicht zu kurz:

var banane = 1.234;
var orange = "Test";
console.log("Mein %a hat den Wert %d", orange, banane);

Ästheten können auch Gruppen bilden, welche in der Konsole sauber dargestellt werden:

console.group('meine Gruppe');
    console.info('Info1');
    console.debug('Was ich wissen wollte...');
console.groupEnd();

Über noch mehr Möglichkeiten dieser Funktionen, wie z.B. Zeitwerte, Stacks u.s.w kann man sich hier auf der Seite von Firebug informieren.

Übrigens:
Die meisten dieser Funktionen sind mittlerweile auch im Debugger des Google Chrome verfügbar!

PING 1.1.1.1 -n 1 -w 25000 >nul

Ja, genau. Das PING-Kommando kann als WAIT-Alternative verwendet werden!

Ein paar ergänzende Erklärungen:

• Die IP-Adresse 1.1.1.1 verweist auf das erste Netzwerk-Device/Karte, daher sollte diese Adresse in den allermeisten Fällen für ein System verfügbar sein.
• Der Parameter -n 1 setzt die Anzahl der Ping-Versuche auf 1.
• Der zweite Parameter -w steht für die Wartezeit. Bitte beachten Sie, dass hier die Angabe in Millisekunden erfolgt, sodass der im Beispiel verwendete Wert 25000 tatsächlich 25 Sekunden entspricht.
• >NUL routet den Datenstrom aus dem Output in das sogenannte Null-Device, damit wird jede Eingabe oder Antwort dieses Streams akzeptiert und weggelöscht.

Natürlich versuche ich immer, WAIT-Operationen in Programmen und Scripts zu vermeiden, aber manchmal hilft es doch, gerade beim Testen. Außerdem ist dies kein sehr exakter Ansatz, hier sollte man also nicht mit einer Atomuhr nachmessen. Dennoch ist dieser kreative Ansatz eine kleine, aber feine Lösung, falls man doch mal um ein WAIT nicht herumkommt…!

Hier gibt es den Artikel des Variety Magazins.

Noch Fragen!?

Eine gute, Coffescript-basierte Seite, welche dieses doch manchmal relativ abstrakte Thema on-thy-fly visualisiert, kann hier gefunden werden:

http://visualsort.appspot.com

Weisheit 2:
Falls die Authentifizierung von Clients einer einfachen Windows-Heimnetzgruppe nicht funktioniert, könnte es auch daran liegen, dass die Systemzeit der Clients voneinander abweichen.

Weisheit 3:
VPN-Probleme können durchaus auch durch einen alten Router ausgelöst werden.

Nicht nur der Buschfunk funktioniert, natürlich wurde das System überparteilich behandelt und erhielt mediale Aufmerksamkeit (Hessischer Rundfunk, Frankfurter Rundschau, Frankfurter Neue Presse, auch Sat1 meldete sich).

Die Stadt will vorrangig vermeiden, dass die personengebundenen Dauerkarten missbraucht werden und durch den Zaun an andere Schwimmbadbesucher durchgereicht werden. Außerdem sollen Personalkosten an Kassen reduziert werden. Eigentlich eine gute Idee, oder?

Der Einsatz des Fingerabdrucks jedoch weckte den Datenschutz-Drachen. Politiker, Juristen, Datenschützer melden sich zu Wort und kritisieren das Verfahren.

Die Diskussion amüsiert mich ein wenig, denn sie verläuft öffentlich derzeit sehr oberflächlich. Bei all dem Gerede vermisse ich eine klare Beschreibung, wie es technisch denn nun genau funktioniert. Ein Indiz fand ich in einem Artikel, darin hieß es, dass die Daten schließlich nicht zentral gespeichert, sondern nur auf dem Chip vorliegen würden. Das sagt nicht viel.

Wie wäre es garantiert nicht sauber?
Auf dem Chip sind (womöglich im Klartext) die Merkmale vom Fingerabdruck des Trägers gespeichert. Bei der Prüfung am Fingerabdruck-Scanner fragt dieser die gescannten Merkmale bei einen Server an, auf welchem die Merkmale auch gespeichert sind.

So bitte nicht. Wenn die Technik so funktioniert, schlage ich mich sofort auf die Seite der Datenschützer. Provinzposse.

Wie wäre es sauber?
Auf dem Chip ist ein Hashwert für die Merkmale des Trägers gespeichert. Bei der Prüfung am Fingerabdruck-Scanner bildet das Gerät ebenso einen Hashwert der Merkmale und vergleicht das Ergebnis mit dem Chip. Die Merkmale selbst werden gar nicht gespeichert, sondern nur zur Ermittlung des Hashwerts verwendet.

Falls dies hinter dem Verfahren steht, gut gemacht! So gehts, so ist es in Ordnung.

Ein Hashwert kann natürlich geknackt werden, damit hätte man das System gehackt, aber dennoch nicht die dem Hash zugrunde liegenden Daten des Fingerabdrucks. Was hätte der Angreifer davon? Er hätte Zugang ins Freibad! Dafür lohnen sich hochkomplexe Hashwert-Attacken…

Zuletzt im Hackerclub:
Hacker-Azubi zum Chef:
“Nun versuchen wir uns an Biometrie. Was hacken wir jetzt? Den Personalausweis? Bankensysteme? Zugriffe zu High-Security-Gebäuden? Atomkraftwerke? Rüstungskonzerne?”

Chef:
“Nein…viel besser… wir hacken das Bad Orber Freibad!”

Wem das zuviel Sarkasmus ist… sorry!

Ich würde mich freuen, wenn das Verfahren etwas genauer beschrieben wird. Dann könnte man sich ein gesundes Bild davon machen, ob es sich hierbei um eine Provinzposse oder um ein zukunftsweisendes Verfahren handelt.

Die Software wird im GitHub verteilt, ist gut dokumentiert, weit verbreitet (guckt mal in viele größere Klassen rein, man stolpert oft über den einen oder anderen Testordner) und genießt hohes Ansehen bei Entwicklern. Die Software ist auch im PEAR und kann darüber installiert werden (ein paar Dependencies gibt es für zusätzliche Funktionen).

An einem einfachen Beispiel möchte ich die grundsätzliche Verfahrensweise demonstrieren. Angenommen, in einem PHP-Projekt gibt es irgendwo eine Funktion, welche den Ostersonntag eines Jahres bestimmt. Der Einfachheit halber nennen wir sie easter($jahr). So eine Funktion könnte beispielsweise eingebunden sein, wenn es um die Errechnung von verschiedenen Feiertage geht – somit könnte sie eine gewisse Kritikalität im Projekt innehaben. Wie testet man nun so eine Funktion mit PHPUnit?

Ich steige hier mal mitten in PHPUnit ein:

require_once 'includes/functions.php';
 
class EasterTest extends PHPUnit_Framework_TestCase {
  public function testEasterOk() {
    $easter2011 = easter(2011);
    $this->assertEquals($easter2011, gmmktime(0,0,0,4,24,2011));
  }
 
  public function testEasterFalse() {
    $easter2011 = easter(2011);
    $this->assertNotEquals($easter2011, gmmktime(0,0,0,12,24,2011));
  }
} 

Zuerst habe einen Verweis auf das PHP-Script (hier: functions.php), in welcher die Funktion easter($Jahr) enthalten ist. Dann generiere ich eine Klasse (“EasterTest”), welche PHPUnit erweitert. In dieser Klasse sind zwei Tests abgelegt:

• Ein Gutfall (ist der 24.4.2011 Ostern?)
• Ein Schlechtfall (ist der 24.12.2011 Ostern?)

Jetzt kommt der trockene theoretische Teil…
Hier geht es nicht etwa darum, das Ergebnis zu finden – das hat man ohnehin schneller mit einem Blick auf dem Kalender. Vielmehr ist es Ziel, das Ergebnis der Funktion mit einem definierten “Wunschergebnis” zu vergleichen. Ich weiß, dass der 24.04. dieses Jahr der Ostersonntag ist… und ich weiß, dass es der 24.12. definitiv nicht ist.

PHPUnit – wie auch fast alle andere Software in diesem Umfeld – arbeitet mit “Assertions” (Behauptungen). Es gibt eine Sammlung von einfachen Funktionen, welche solche Assertions in verschiedenen Konstrukten ermöglichen – angefangen von Vergleichsoperationen wie die im Beispiel verwendeten assertEquals und assertNotEquals über False/True-Varianten, Array-Prüfern und einigem anderen.

Ist dies viel Arbeit?
Bitte urteilt selbst.. ein einfacher Test ist fix geschrieben. Nicht schwer, oder?

Zurück zur Praxis.
Wie kann man nun die Tests auswerten? Am einfachsten über die Shell. Und hier ist es nun wirklich egal, ob man sich in einer Dosbox, Bash oder wo auch immer aufhält.

D:\htdocs\>phpunit EasterTest.php
PHPUnit 3.5.11 by Sebastian Bergmann.

..
 
Time: 0 seconds, Memory: 3.75Mb
 
OK (2 tests, 2 assertions)

PHPUnit kann auch andere Output-Formate, beispielsweise das TAP-Format (“Test Anything Protocol”), JSON, XML und andere.

D:\htdocs\>phpunit --tap EasterTest.php
TAP version 13
ok 1 - EasterTest::testEasterOk
ok 2 - EasterTest::testEasterFalse
1..2

Wenn ich nun in einem Test einen Fehler habe, sieht das so aus (ich habe hierfür den Test 1 so verändert, dass die Behauptung lautet, der 23.04.2011 wäre Ostersonntag – ist aber in Wirklichkeit der Samstag davor):

D:\htdocs\>phpunit --tap EasterTest.php
TAP version 13
not ok 1 - Failure: EasterTest::testEasterOk
  ---
  message: 'Failed asserting that <integer:1303516800> matches expected <integer:1303603200>.'
  severity: fail
  data:
    got: 1303516800
    expected: 1303603200
  ...
ok 2 - EasterTest::testEasterFalse
1..2

Wenn ich nun – wann und warum auch immer – an der eigentlichen Funktion wieder mal arbeite, dann habe ich weiterhin meine gespeicherten Tests. Wenn diese mir also Mist zurückgeben, ist entweder mein Test falsch (eher unwahrscheinlich), oder meine veränderte Funktion ist nicht ok… und genau darum geht es hier. Modultests wie dieser hier machen den Code deutlich stabiler und nachträgliche Arbeiten, Erweiterungen etc. erheblich einfacher.

Und wenn es mal Bugs gibt… schreibt einen Test und fixt dann den Bug!