Archiv der Kategorie: phpUnit

How to fix „SSL certificate problem: unable to get local issuer certificate“ on Windows

Schreibe eine Antwort

Du weißt bestimmt, dass ich auf Windows entwickle. Im Gegensatz zu vielen, die auf Macs oder Linux schwören, bleibe ich hartnäckig auf Windows – auch wenn dies bedeutet, dass ich Probleme sehe, die für andere unsichtbar sind. Ich sehe da allerdings die Chance, mehr zu lernen.

Eins dieser „mehr lernen“ Erfahrungen hatte ich heute. Meine phpunit tests laufen automatisch bei github und travis durch, keine Fehlermeldungen, alles gut.
Bis ich dann eben die Tests auf meiner Konsole ausführen wollte:

Anstelle des Erwarteten Fehlers SSL: no alternative certificate subject name matches target host name 'domain.xyz' erwartet mich:

SSL certificate problem: unable to get local issuer certificate

Wie seltsam … jetzt starte ich phpunit mal in meiner WSL Umgebung und siehe da, die Tests laufen alle durch. Das wieder so ein „Typisch Windows“ Problem.

Die Ursache liegt darin, dass du bei Windows-PHP-mit-Curl keine Zertifikatsinformationen per default eingestellt hast … das kann jetzt gut und schlecht sein, auf jeden Fall führt das zu dem Fehler.

Es gibt dazu allerdings auch eine Lösung und die funktioniert recht einfach:

1. Downloade gültige Zertifikatsinformationen von https://curl.se/ca/cacert.pem
2. Benenne die Datei um in curl-ca-bundle.crt
3. Kopiere die Datei, wo du sie gut verwalten kannst, bei mir liegt die in D:/www
4. Editiere deine php.ini. Du musst folgende Einträge ändern:
4.1. curl.cainfo = D:/www/curl-ca-bundle.crt
4.2. openssl.cafile=D:/www/curl-ca-bundle.crt
5. Speichern und Apache neu starten

Und nun laufen auch meine Tests durch ?

 

Von phpUnit zu Codeception wechseln

Schreibe eine Antwort

Codeception-LogoWenn du vom klassischen phpUnit zu Codeception wechseln möchtest, musst du erschreckend wenige Sachen beachten. Dafür bekommst du am Ende dann die vielen Vorteile von Codeception. Ob sich das für dich und dein Projekt lohnt, musst du latürnich (sic!) selbst für dich und dein Projekt entscheiden. Mir fiel die Wahl leicht…

Wie ich schon sagte, es braucht erschreckend wenig, damit Codeception die Tests übernimmt, da sich der „unit“ Teil nicht sooo stark von phpUnit unterscheidet. Ganz im Gegenteil ruft Codeception auch phpUnit unter der Haube auf. Du hast nur den Vorteil einer einheitlichen Test-Strategie und -Sprache und musst nicht eine Vielzahl von Dialekten behalten (phpUnit, Selenium, wtf, …).

Ich nehme mal an, dass deine unit-tests bereits funktionieren und dass diese im verzeichnis „tests“ liegen. Falls nicht, das „tests“ Verzeichnis solltest du schnell mal anlegen und deine Tests von dort aus starten 😉 Dann wird’s leichter.

Also los, die ersten Erfolge sind schnell gemacht:

  • Codeception „installieren“
    Sprich, die „codecept.phar“ ins root deines Projektes kopieren.
  • Per Konsole (phpStorm hat die ja eingebaut, sehr praktisch)
    „php codecept.phar bootstrap“
    Nun werden Grundlegende Sachen im Verzeichnis „tests“ angelegt.
  • Kopiere deine alten tests mit einer Sinnvollen Verzeichnisstruktur in das Verzeichnis „tests/unit“
  • benötigte Datenbank-Dumps kommen erstmal in „tests/_data/dump.sql“
  • Deine „tests/unit.suite.yml“ sollte in etwa so aussehen: 
    class_name: CodeGuy
modules:
 enabled: [Unit, CodeHelper, Db]
 config:
  Db:
   populate: true
   cleanup: false
  • In der „codecept.yml“ trägst du die Datenbankzugangsdaten für die tests ein, dann brauchst du die nicht in der „unit.suite.yml“ eintragen und die gelten somit codeception-weit, was später die Function- und Acceptance-Tests vereinfacht.
  • In deinen Tests musst du nun noch folgende Anpassungen machen, damit alles reibungslos funktioniert:
    • Die Testdatei fängt immer mit 
      use Codeception\Util\Stub;

      an.

    • Die Tests erweitern nun 
      \Codeception\TestCase\Test

      also

      class myWhateverTest extends \Codeception\TestCase\Test {
 // ...
}
    • Die Methoden „setUp()“ und „tearDown()“ werden zu „_before()“ und „_after()“. Denkt auch an den Aufruf parent::_before() und parent::_after() in den Methoden!
  • Eure bisherige „bootstrap.php“ muss in „tests/_bootstrap.php“ oder ihr passt die „codecept.yml“ einfach an.

Damit steht nun das Grundgerüst und ihr könnt via

php codecept.phar run

eure Tests ausführen.

In meinem konkreten Fall konnte ich damit die Tests einer ZF1 Application mit Anlegen und Füllen einer Testdatenbank (MySQL) um den Faktor 8 beschleunigen. Zusätzlich kann nun recht einfach neue Tests in Codeception einfügen und die Ergebnisse stehen mir ebenfalls für Jenkins und Co zur Verfügung, teilweise mit sehr viel höherer Aussagekraft.

Viel Erfolg…

Rezension: Softwarequalität in PHP-Projekten von Sebastian Bergmann und Stefan Priebsch, 2. Auflage

Eine Antwort

Man kann sich viele Bücher zum Thema Qualitätsverbesserung in IT-Projekten zulegen, manchmal kann man während der Lektüre sogar was lernen, in den wenigsten Fällen hat man es dabei mit konkreten Programmiersprachen zu tun und noch viel weniger sind in Deutsch.
Da scheint es ein wahrer Lichtblick zu sein, dass zwei der bekanntesten PHP-Experten das Standardwerk zur Qualitätsverbesserung und -sicherung noch einmal überarbeitet haben, teilweise sogar neu geschrieben haben. Herausgekommen ist ein absolutes „must-have“.

Sebastian Bergmann und Stefan Priebsch beschreiben auf circa 460 Seiten, worauf der Qualitätsbewusste PHP-Entwickler achten muss und soll. Angefangen vom „Was ist denn eigentlich Qualität und wie kann man diese Messen?“ über „und warum ist das wichtig?“ bis hin zum „Wie sag ich’s meinem Kunden“ schreiben beide in einem lockeren Stil über eines der komplexesten Themen innerhalb des Programmieralltags.

„Softwarequalität in PHP-Projekten“ ist sicherlich kein Buch zum einfachen „runter lesen“, sondern man ertappt sich öfters dabei, eine Seite nun das x-te mal gelesen und dann doch noch das Gefühl zu haben, etwas nicht richtig verstanden zu haben. Kleiner Tip: Hier hilft es sehr, die Beispiele wirklich abzutippen und das Thema mal auszuprobieren. Frei nach dem Motto „Probieren geht über Studieren“ lösen sich dann die Fragen meist in Erkenntnis auf.

Schön zu lesen sind auch die Fallbeispiele von Typo3, Zend Framework und allen weiteren. Auch die „großen“ machen Fehler und manche lassen sich hier nachlesen. Das schöne Gefühl von „die konnten es auch nicht sofort“ stellt sich ein und lässt einen etwas beruhigter zurück.

Meine Favoriten waren die Kapitel über „Legacy Code“, „Kontinuierliche Integration“ und „Bad Practices“. Ich persönlich fand ich den präsentierten Legacy Code zwar nicht legacy genug, aber das liegt sicherlich auch an mir und meinem Background. Übertragbar sind trotzdem viele der Wege und Tips auf (noch viel) älteren Code – alles schon ausprobiert 😀

Will man nun was negatives finden, man könnte anbringen, dass die Beispiele in sich manchmal nicht konsistent sind oder der eigentlich Kern, was Bergmann und Priebsch sagen wollen, nicht immer anhand der Beispiele ersichtlich wird. Hier und da hätten die Beispiele kürzer, dafür mehr auf den Kern reduziert sein können, es hätte zu etwas schnelleren „Aha!“-Momenten geführt. Aber das wäre jammern auf einem sehr hohen Niveau. Dieses Buch richtet sich definitiv nicht an Einsteiger, die sich an solchen Dingen stören würden; es richtet sich vor allem an Profis oder interessierte Fortgeschrittene, die sich noch weiter verbessern wollen, noch näher an den „perfekten Code“ kommen wollen. Und dieses Wissen zu vermitteln schafft dieses Buch locker.

Mein Tip: Kaufen, Lesen, Verstehen (nicht auswendig lernen). Ich habe selten so ein gutes (Fach-)Buch gelesen! Wenn ihr nur wenig Budget zur Verfügung habt, euch aber die Qualität eures Codes (und eures Handwerks) nicht egal ist, dann kauft dieses Buch. Ihr werdet sehr lange Lesefreude daran haben und euer Code wird es euch danken.

tl;dr: Unbedingt kaufen und verinnerlichen

XDebug Logo

XDebug und Zend Server CE für Unit Tests und Code Coverage Reports

Schreibe eine Antwort

Wer Unit Testing betreibt, der will auch Code Coverage, ganz klare Sache. Für Code Coverage benötigt man in Verbindung mit phpUnit XDebug. In der Regel kein Problem.

Wer allerdings den ZendServer benutzt der war bisher angeschmiert, den XDebug im ZendServer zu konfigurieren kann nervig sein und eine falsch eingetragene Zeile kann den Betrieb des ZendServers sogar komplett lahmlegen.

Aber natürlich gibt es einen Weg, XDebug, ZendServer inkl. ZendDebugger laufen zu lassen, du bekommst also den ZendDebugger zum debuggen und XDebug zum Unit Testen deiner Anwendung, das beste aus beiden Welten – unter Windows 😉

Bereit? Los geht’s:

  1. ZendServer stoppen, entweder per Dienstkonsole oder mit „Apache Service Monitor“
  2. Lade dir die fehlende XDebug dll bei XDebug.org runter.
    Welche ist die passende?
    Zunächst erstmal die PHP Version deines ZendServers, dann den Link OHNE „TS“ und den mit 32-Bit, der sollte passen – war bisher bei allen meinen ZendServer-Installationen so.
    Beispiel mit PHP 5.4: „PHP 5.4 VC9 (32 bit)“
  3. Die .dll legst du nun im Verzeichnis 
    /ZendServer/lib/phpext

    deines ZendServers ab.

  4. Nun ab in die php.ini
    Dort trägst du ziemlich weit unten aber ÜBER diesem Eintrag:

    zend_extension="C:\zend\ZendServer\lib\ZendExtensionManager.dll"

    (Pfad ist bei dir zumindest ähnlich)
    das hier ein:

    zend_extension="C:\zend\ZendServer\lib\phpext\php_xdebug-2.2.2-5.4-vc9-nts.dll"

    Natürlich ersetzt du den konkreten Namen durch deinen, bei mir ist das der ZendServer mit PHP 5.4 in der zum Veröffentlichungszeitpunkt aktuellsten Version von XDebug.

  5. Spaß mit Code Coverage!
    Ja, genau, schon fertig.

Ab nun kannst du Code Coverage Reports bekommen.

Was nicht geht: Du kannst mit XDebug (höchstwahrscheinlich) nicht wirklich debuggen – aber du hast ja den Zend Debugger, der zumindest mit dem Zend Studio wesentlich besser funktioniert.

Ich selbst habe bisher keine verlässlich funktionierende Konfiguration gefunden, mit dem ich via XDebug im Zend Server debuggen und profilieren konnte; mir reicht XDebug zum erzeugen der Code Coverages.

Vielen Dank geht an „Limespacer“ für diesen Beitrag, der mir dabei sehr geholfen hat:
http://www.limespace.de/2009/07/15/zend-server-ce-mit-xdebug/

P.S. Bei mir geht es auch mit aktiviertem Zend Debugger, falls das bei dir nicht der Fall sein sollte, dann schalte diesen wie im verlinkten Beitrag gezeigt einfach ab.