WebTec PHP 5

Ein Namensraum im PHP-Code ist ein Bereich der mit einem eindeutigen Namen versehen ist. Dieser kann mehrere Klassen, Funktionen oder Konstanten (von PHP oder Drittanbietern) enthalten, die über den Namensraum in verschiedenen Projekten/Teilprojekten wiederverwendet werden können.

Die Packages in Java sind vergleichbar, da diese über ihre Klassenzugehörigkeit in anderen Java-Klassen wiederverwendet werden können.

Für eine Klasse:
use \NameNamensraum2\Klassenname;

Für eine Funktion (bzw. eine Methode):
use function \NameNamensraum2\Funktionname;

Bei beiden könnte man den Zusatz „as XXX“ damit im Projekt einen neuen Namen vergeben wird, mit dem man dann die einzelnen Aufrufe macht.

Anonyme Funktionen haben keinen Namen, sind ansonsten aber normale Funktionen. Bei der Definition einer anonymen Funktion wird diese einer Variable zugewiesen.

Anonyme Funktionen werden häufig für zur Generierung von Callback-Parametern genutzt. Beispielsweise zur Weitergabe des Ergebnisses einer Funktion an eine Andere

Hier wird der aktuelle Wert der Variablen zum Zeitpunkt der Definition der Funktion festgehalten. Daher ist das Ergebnis „Hello World“ und nicht „Bye Bye World“.

Derartige Funktionen werden Closures genannt.

Man könnte aber auch mit dem Identifier „global“ arbeiten.

Kurz → mit „use …“ wird der Wert der Variable zum Zeitpunkt der Funktionsdefinition übergeben!

Man registriert erst mal die Funktion „loader“ im Stapel.

PHP wird dann bei der Erzeugung von „MyClass“ automatisch die Funktion „loader“ aufrufen. Diese bindet dann die Datei „Myclass.php“, falls existent, ein. Nun wird PHP nochmal versuchen, ein Objekt der Klasse „MyClass“ zu erzeugen. Gelingt dies immer noch nicht, wird ein Standardfehler angezeigt, dass die Klasse nicht geladen werden konnte.

Unit-Tests werden in der Softwareentwicklung angewendet, um die funktionalen Einzelteile (Units) von Computerprogrammen zu testen, d. h., sie auf korrekte Funktionalität zu prüfen.

Die Unit-Tests sind in der Regel vollständig automatisiert, bzw. sin selbst ein Programm, dessen Ausführung nicht mehr Aufwand als einen Knopfdruck erfordert. Dabei ist es üblich, dass der Test in der gleichen Sprache wie das Testobjekt geschrieben wird.

?

TDD → Test Driven Development

Bei dieser Methode werden zuerst die Testfälle definiert, dann die zu testende Klasse realisiert. Das heißt, die Programmierung ist an den Testfällen orientiert und nicht andersrum.

Der Name der Testklasse muss mit „test“ enden und muss der Dateiname dem Klassennamen entsprechen.

Beispiel:

• zu testende Klasse → „Percent“
• Testklasse → „PercentTest“

Die Testmethoden müssen mit „test“ beginnen.

Beispiel: testGetPercent()

Mit Hilfe von assert*()-Routinen werden Ergebnissen geprüft. Diese Routinen sind in den Testmethoden enthalten. Beispiele:

o   $this -> assertTrue($bool);/assertFalse($bool) → prüft ob true oder false

o   $this -> assertEquals($expected, $actual) → vergeicht auf ein erwartetes Ergebnis

●      Grün → wenn der Testfall erfüllt wird, bzw. dem erwarteten Ergebnis entsprochen wird.

●      Rot → wenn der Testfall nicht erfüllt wird oder der Testfall ignoriert bzw. gesprungen wird.

Für Tests, die eine debug-Eigenschaft aktiviert haben, wird auch die Farbe rot angezeigt.

(Felix → rot wird auch für die Tests angezeigt, die ignoriert wurden)

Der Testrunner ist eine Art Treiber, der die einzelnen Tests automatisch nacheinander aufruft. Ablauf: unter 9. beschrieben.

$this-> expectException($class);

Eine Exception $class wird erwartet.

Beispiel:

$this-> expectException($InvalidArgumentException::class);

InvalidArgumentException::class bedeutet, dass hier ein Deskriptor für eine Klasse übergeben wird. Dies ist die erwartete Klasse bzw. das erwartete Objekt von dieser

Klasse. (::class gehört zum Bereicht der Reflexion).

Prüft einen übergebenen Ausdruck auf TRUE und zeigt andernfalls einen Fehler an. Ist der Ausdruck korrekt, wird keine Meldung angezeigt.

assert() sollte nur zum Debuggen des Codes verwendet werden. Es kann für Plausibilitätsprüfungen verwendet werden, um auf Bedingungen zu prüfen, die immer TRUE sein sollten, und die andernfalls Programmierfehler anzeigen, oder um auf die Verfügbarkeit bestimmter Merkmale, wie Erweiterungsfunktionen oder bestimmte Systembeschränkungen und Eigenschaften, zu prüfen.

Zusicherungen sollten nicht für normale Laufzeitoperationen wie die Überprüfung von Eingaben verwendet werden. Als Faustregel sollte der Code immer korrekt funktionieren können, auch wenn die Zusicherungsüberprüfung deaktiviert ist.

Man könnte die assert-Überprüfungen ausschalten. Es gibt 2 Wege:

●      Durch das Setzen von Konfigurationsdirektiven → init_set(‚zend.assertions‘, 0)

●      Mit assert_options() → assert_options(ASSERT_ACTIVE, 0)

In Java vorhanden, in JavaScript nicht.