Sie sind nicht angemeldet.

Lieber Besucher, herzlich willkommen bei: Webgamers. Falls dies Ihr erster Besuch auf dieser Seite ist, lesen Sie sich bitte die Hilfe durch. Dort wird Ihnen die Bedienung dieser Seite näher erläutert. Darüber hinaus sollten Sie sich registrieren, um alle Funktionen dieser Seite nutzen zu können. Benutzen Sie das Registrierungsformular, um sich zu registrieren oder informieren Sie sich ausführlich über den Registrierungsvorgang. Falls Sie sich bereits zu einem früheren Zeitpunkt registriert haben, können Sie sich hier anmelden.

BlackScorp

Moderator

  • »BlackScorp« ist der Autor dieses Themas

Beiträge: 1 284

Wohnort: 127.0.0.1

Danksagungen: 568

  • Nachricht senden

1

Dienstag, 30. Dezember 2014, 10:08

Verantwortung

Hallo leute,

wie einige sicherlich wissen, "predige" ich von der Clean Code Architektur, der Grund hierfür ist, dass sehr viele PHP Entwickler unverantwortlich sind, verlassen sich komplett auf Frameworks/Libraries und bauen sich Sicherheitslücken ein.

Vielleicht erkläre ich hier mal worum es bei der Architektur geht und welche Probleme man beheben möchte.

Als erstes kommen Automatisierte Tests, diese sind nicht dazu da um irgendwie "Cool" zu wirken, Automatisierte Tests helfen auch nicht gegen Bugs/Sicherheitslücken(nicht zu 100%). Automatisierte Tests können euch sagen ob ein Bestimmtes Feature so funktioniert wie erwartet. Selbst wenn sich an anderen Stellen etwas verändert, können die Tests einem Sagen ob ein Bestimmtes Feature immer noch funktioniert. Das Gleiche gilt auch für Bugfixes. Statt ein Bug zu beheben und hoffen dass er auch in Zukunft nicht Auftritt, behebt man den Bug nicht nur sondern schreibt auch ein Test dazu.

Nun ist es aber nicht besonders einfach Tests zu schreiben, nutzt man noch Frameworks kann es auch noch länger dauern. Oft möchte man nur eine Funktion testen doch mit Frameworks geht man dann über den Request -> Router -> Controller Resolver bis zum Response des Frameworks, und das dauert. Vielleicht nicht direkt am Anfang aber spätestens wenn ihr 20 Minuten warten müsst bis all eure Tests durchgelaufen sind. Durch die Lange warte zeit hat man dann einfach keine Lust weitere Tests einzubauen und die Anwendung wird fragil.

Frameworks sind eigentlich was gutes, man hat i.d.r eine tolle Dokumentation, man erstellt Dateien in Bestimmten Ordnern, man passt ein wenig Konfigurationen an und schon hat man Relativ schnell eine Anwendung erstellt. Die Clean Code Architektur soll lediglich dazu dienen, die Logik aus dem Framework zu separieren, so dass man es eben Schnell Testen kann.

Wenn Ihr schnell Testen könnt, habt ihr keine Hemmungen mehr die neuste Bibliotheken via Composer einzusetzen, denn dass ist das Nächste Problem.

https://github.com/Roave/SecurityAdvisories

mit diesem Package habt ihr die Möglichkeit, Libs/Plugins zu installieren, die NICHT von Sicherheitslücken betroffen sind (Es aber eventuell irgendwann sein können). Das Framework an sich bietet ja immer Backward Compatibility an jedoch einzelne Bibliotheken die man in seiner composer.json hat, können durchaus andere Versionen des Frameworks oder von anderen Bibliotheken verlangen.

Ohne Tests könnte man durchaus vor folgenden Wahlen stehen.
1) Ich werde kein composer update ausführen und hoffen dass meine Seite nicht gehackt wird(Ich meine ich bin ja nicht Google oder ebay, keiner Interessiert sich für mich also wird da nichts passieren)
2) Ich muss sehr viele Stellen im Code anpassen und hoffen dass meine Seite immer noch so funktioniert wie früher und zur Not nutze ich eben meine Kunden als Tester, die werden schon ein Bug melden, wenn sie ein finden.
3) Ich ersetze eine Bibliothek mit der Sicherheitslücke mit einer anderen, passe stellen im Code an und gehe zu Punkt 2


Was ich sagen will, zu sagen ich habe keine Zeit um Tests zu schreiben ist einfach nur Verantwortungslos, wir als Webentwickler verdienen um einiges Mehr als sagen wir ein Tischler oder Frisör, doch das was wir bei der Täglichen Arbeit produzieren ist in vielen Fällen einfach unter aller Sau, stellt euch Vor ein Tischler würde sagen, nehme ich doch ne Dünne Platte für einen Tisch, der Kunde weis ja nicht dass diese Platte nur ein geringes Gewicht aushalten kann.

Bei einem Tischler können wir aber selbst nachprüfen und mit ein wenig Logischen verstand nachvollziehen dass da gepfuscht wurde. Leider haben in der Gesellschaft die wenigsten nicht Entwickler eine Ahnung was ein Programmierer tut.(Sieht man sehr oft wenn einer sagt, du bist doch Programmierer, kannst du mir ein antivirus Programm installieren?)

Deshalb predige ich ständig von der Clean Code Architektur.

http://blog.ircmaxell.com/2014/12/being-…-developer.html Hier ist übrigens der Beitrag der mich dazu Brachte dieses zu schreiben. Eigentlich wollte ich nur ein Satz hinschreiben, ist wohl doch etwas mehr geworden.
Qualität eines Codes misst man in WTF/Sekunde

Es hat sich bereits 1 registrierter Benutzer bedankt.

Benutzer, die sich für diesen Beitrag bedankt haben:

Mina (31.12.2014)

andy

Schüler

Beiträge: 75

Wohnort: Wien

Beruf: Web Entwickler

Danksagungen: 51

  • Nachricht senden

2

Dienstag, 30. Dezember 2014, 13:32

Also muss sagen sehr gut geschrtieben und das mit den Tests da hast du aufjedenfall Recht, ich merke es andauernd bei mir in der Arbeit, es muss alles schnell gemacht werden zum gscheit testen kommst du nicht mal
und wenn du es dem Kunden dann gibst und Fehler auftreten heisst es du hast schuld... wobei du eigentlich keine Zeit hattest ein Testscript zu schreiben bzw. alle Funktionen zu testen...

BlackScorp

Moderator

  • »BlackScorp« ist der Autor dieses Themas

Beiträge: 1 284

Wohnort: 127.0.0.1

Danksagungen: 568

  • Nachricht senden

3

Dienstag, 30. Dezember 2014, 13:58

Naja ich denke man hat IMMER Zeit die Tests zu schreiben, was man aber nicht machen kann, ist das Isolieren der Logik aus dem Ganzen Projekt um eben nur einen kleinen Teil bzw ein spezielles Feature testen zu können.

Es ist eine Art Teufelskreis. Man hat keine Zeit oder es ist schlichtweg nicht möglich Teile aus dem Projekt "raus zuschneiden" um die zu Testen, dadurch hat man keine Zeit Tests zu schreiben, dadurch muss man die Zeit ins Manuelle Testing investieren und dadurch hat man keine Zeit um Tests zu schreiben.

Wenn man doch ganz ehrlich ist, man findet die Zeit sich das Ergebnis auf der Seite anzusehen, eventuell was nach zu pflegen und das neue Resultat wieder auf der Webseite ansehen.
Fixt man ein Bug, so schaut man ja auch nicht jede Stelle, jedes Feature der Webseite noch mal an, es hat ja vorher immer funktioniert.
Ich sehe es eher so dass das manuelle Testing eine Zeitverschwendung ist und dafür nutzt man gerne Zeit(irgendwie absurd).

Andererseits kann man Automatisierte Tests nicht von einem Entwickler direkt verlangen und nur wenige Firmen schulen ihre Entwickler darauf. Da die Meisten Chefs sich denken, "Der hat ja eine Ausbildung gemacht, der weis was er tun soll" kommt es dazu dass Anfänger, Kostenintensive Projekte realisieren, nur weil diese 2 Jahre in einer Firma arbeiten.

Auch werden die Erfolge eines Projektes viel zu Simpel gemessen, Es ist nur wichtig wie schnell man ein Feature/Projekt abgeschlossen hat. Es gibt aber noch weitere Variablen die Total ignoriert werden.

*) Bugs over time
*) Wiederkehrende Bugs over time
*) Zeit für neue Features
*) Zeit für Anpassung an neue Systeme/Standards
*) Zeit für Einarbeitung neuer mitarbeiter
*) Dokumentationspflege

Das sind auch wichtige Faktoren, die total ignoriert werden.
Qualität eines Codes misst man in WTF/Sekunde

andy

Schüler

Beiträge: 75

Wohnort: Wien

Beruf: Web Entwickler

Danksagungen: 51

  • Nachricht senden

4

Dienstag, 30. Dezember 2014, 14:06

Aber du redest jetzt von geschriebenen Test abläufe was ist deine Meinung zu Visuallen Tests alla http://www.seleniumhq.org/, dies wird z.B. bei unserer Web Applikation in der Firma eingesetzt um Formularte und verschiedene Akitonen durchzutesten...

BlackScorp

Moderator

  • »BlackScorp« ist der Autor dieses Themas

Beiträge: 1 284

Wohnort: 127.0.0.1

Danksagungen: 568

  • Nachricht senden

5

Dienstag, 30. Dezember 2014, 14:24

Man nutzt Dinge wie Selenium eben deshalb weil die Logik Direkt in dem Controller drin steckt, ich brauche zum Beispiel nicht mal ein Formular um irgendwas auszuprobieren, ein Simpler array mit Werten, wird durch eine Funktion gejagt und es wird geschaut ob bestimmte Werte im Ergebnis drin stecken.

Man nutzt die Dinge weil es einfach ist. Es ist eher eine Art Fake, man möchte sich nicht mit den Ursachen befassen , man ist sich aber den Risiken bewusst, also verwendet man ein Tool der mir mit wenig widerstand teilweise erwartete Ergebnisse liefert.

Wie sieht es denn aus mit Silinemum wenn ihr eure Layout Struktur verändern wollt? Selenium ist ein DOM Crawler, verändert sich das Layout, so muss man die Tests verändern.

Ich habe auch von einigen hier die Phrase gehört "Code once, run forever" das ist natürlich ein Wunschdenken und mit Clean Code nicht realisierbar, aber man kann damit mit weniger schmerzen vieles im Code verändern. Man ist anpassungsfähiger auf die Gegebenheiten. Verändert sich das Layout.. ist mir doch egal, muss ich meine Features als Hintergrund Prozess laufe lassen der als Cronjob gestartet wird , statt einer Ausgabe auf der Webseite.. mir doch egal.. hat ein Framework neue Dependencies, muss ich Framework updaten.. ist mir auch egal .. kommt weitere Datebank Quelle hinzu ? auch egal, man kann die tiefsten Eingriffe in einem Projekt durchführen ohne das Projekt töten zu müssen.

Wegen Zeit, ich kann schaue ob mein User sich auf der Seite registrieren und einloggen kann + weitere Features mit allen Kombinationsmöglichkeiten der Formulare in 161 ms
Diese Tests + die gleichen mit Framework Implementierung(Also mit Controller,Router und Response HTML Check und Richtiger DB) dauert 5 Sekunden. Verändere ich also etwas im Code, brauch ich Maximal 5 Sekunden um zu WISSEN dass ich etwas kaputt gemacht habe.
Qualität eines Codes misst man in WTF/Sekunde

Beiträge: 892

Danksagungen: 327

  • Nachricht senden

6

Dienstag, 30. Dezember 2014, 16:27

Ich verstehe ja nur 20% von dem, was ihr hier so schreibt. Aber da ich die Hoffnung habe, irgendwann wenigstens auf 30% zu kommen, habe ich jetzt mal eine Frage:

Wäre es denn denkbar, dass man ein Clean Code Framework erschaffen könnte? Oder schließt sich das aus? Also "Clean code" und "framework"?

BlackScorp

Moderator

  • »BlackScorp« ist der Autor dieses Themas

Beiträge: 1 284

Wohnort: 127.0.0.1

Danksagungen: 568

  • Nachricht senden

7

Dienstag, 30. Dezember 2014, 16:54

Naja ein Clean Code Framework kann es nicht geben, es ist lediglich ein Prozess/Aufbau der eigenen Architektur, dabei werden die üblichen Design Pattern angewendet.

Wenn du dir den Quellcode wie eine Art Zwiebel vorstellst. So ist der Kern, dein Quellcode und außen rum ist es verpackt durch das Framework.

Es soll ja das Framework nicht ersetzen, es soll dir erlauben Komponente aus allen Frameworks mischen/ersetzen zu können. Es soll erlauben den Code sofort zu Schreiben ohne sich Gedanken machen zu müssen, welches Framework ich nun einsetzen will. Der Kern der Anwendung kann garnicht als Framework exestieren da jede Anwendung ihre eigenen Features hat. Allgemeine Dinge wie MVC/Routing/DI/Validierung das überlässt man dem Framework

hier eine kleine Erklärung dazu

http://rules.ssw.com.au/SoftwareDevelopm…chitecture.aspx

Es geht nur darum. Hat man es geschafft, das was die Anwendung tun soll, zu extrahieren, so kann man es für sich allein schnell testen, und wenn man nicht Testen kann, weis man nie ob man nicht irgendwas zerschossen hat, weil man irgend eine Änderung vorgenommen hat.



Es ist auch so, ich habe öfters auf der Arbeit eins auf den Deckel bekommen, dass durch den Einbau weiterer Features, irgendwo was anderes kaputtgegangen ist, manchmal was es offensichtlich weil man eine Fehlermeldung bekam, das konnte man leicht beheben. Andere Dinge zerstörten wiederum die Logik so dass es keine Fehlermeldungen gab, jedoch nicht korrekte Daten in die Datenbank eingetragen wurden.

Dann habe ziemlich lange versucht zu interpretieren was der Code eigentlich tun soll, was soll das Ergebnis sein(Das wussten sogar die Entwickler nicht mehr weil der Code von vor 10 Jahren geschrieben wurde). Sobald ich wusste wie das Ergebnis aussehen sollte, konnte ich herausfinden wo ich ein Fehler eingebaut habe und wieso gerade diese Stelle beeinflusst wurde. Deswegen sprach ich hier von Verantwortung.

Im Grunde habe ich auf den Deckel bekommen, weil es lange dauerte ein Feature einzubauen + Bugs sind rein gerutscht, weil der Entwickler vor 10 Jahren es nicht wusste wie man Besser macht und hatte "keine Zeit" automatisiert den Script zu überprüfen, auch hatte niemand die Zeit mit neu erlangten Wissen den Quellcode aufzufrischen und früher oder später ist man eben Gezwungen die Zeit, die man nicht hatte, doch irgend woher aufzutreiben und eventuell sogar das Doppelte an der Zeit investieren.
Qualität eines Codes misst man in WTF/Sekunde

Logic Kill

Schüler

Beiträge: 73

Danksagungen: 148

  • Nachricht senden

8

Dienstag, 30. Dezember 2014, 19:51

Hallo,

ich habe die Beiträge hier mit sehr viel Interesse verfolgt und stelle mir nun folgende Frage:

Wie muss ich mir solche Tests vorstellen?
Gibt es ein gutes Tutorial/Beispiel wie ich soetwas am Besten umsetzte?


Ich hoffe das ich damit auch bei meiner Programmierung des BGs im Vorfeld mehr Bugs finde und fixen kann.


Gruß

LK

BlackScorp

Moderator

  • »BlackScorp« ist der Autor dieses Themas

Beiträge: 1 284

Wohnort: 127.0.0.1

Danksagungen: 568

  • Nachricht senden

9

Dienstag, 30. Dezember 2014, 20:13

Ich erstelle gleich ein Tutorial für PHPUnit + Composer
Qualität eines Codes misst man in WTF/Sekunde

Logic Kill

Schüler

Beiträge: 73

Danksagungen: 148

  • Nachricht senden

10

Dienstag, 30. Dezember 2014, 20:18

Ich erstelle gleich ein Tutorial für PHPUnit + Composer

Super danke, das wird sicherlich nicht nur mir helfen.

Kliff

Schüler

Beiträge: 68

Wohnort: Hannover

Danksagungen: 92

  • Nachricht senden

11

Mittwoch, 31. Dezember 2014, 02:18

Hi,

wir hatten uns (vor langer Zeit) in der Uni in einem Projekt mit automatischen Test beschäftigt (Java App für Androide). Damals war es eine Anforderung zu jeden Feature auch einen Test zu schreiben. Ich bin dabei für mich zu dem Schluss gekommen, dass automatische Test nur in sehr wenig Fällen sinnvoll sind. Bei uns entstanden mehrere Probleme:

1. Das Schreiben der Teste war sehr zeitaufwendig. Oft wurde für das schreiben eines Test deutlich mehr Zeit verwendet als für das Feature an sich. Teilweise das 4 Fache der Zeit.

2. Oft sind triviale Test entstanden, die entweder immer bestanden waren oder eine sehr triviale Funktionen testeten.

3. Wenn ein Test nicht bestanden wurde, wurde gefühlt eher der Test angepasst als das Programm. Da in den meisten Fällen der Test das Problem war nicht die Funktion.

4. Durch automatische Tests wurden immer nur die Fehler abgefangen an die man gedacht hat und die daher sowieso schon in der vorher geschriebenen Funktion berücksichtigt wurden. Fehlerquellen die bei der Funktion nicht berücksichtigt wurden, wurden so durch den Test auch nicht berücksichtigt.

5. Obwohl alle Teste bestanden waren enthielt die Software offensichtliche Fehler. Eben solche die nicht durch die Tests abgedeckt wurden. Die Testes gaben so das trügerische Bild die Software wäre fehlerfrei, obwohl sie es nicht war.

Meiner Meinung nach haben die Tests weder dazu geführt, dass besserer Code entstanden ist, noch konnten sie sicherstellen dass die Software fehlerfrei ist. Ich denke es wäre sinnvoller die Zeit ,die für schreiben und ausführen der Tests draufgeht, darin zu investieren, sich Gedanken über den Code und mögliche Fehlerquellen zu machen, oder die Software manuell zu Testen.

Ich kann mir allerdings automatische Teste bei Webseiten schwer vorstellen. Das Ergebnis einer Anfrage ist ja meist ein dynamisches html Dokument oder ein json Objekt welches von Daten in der Datenbank und einer viel Zahl von Parametern abhängt. Wie kann ein automatischer Test jetzt überprüfen ob die Antwort korrekt ist? Ob z.B. alle Informationen richtig dargestellt werden? Es wäre doch nur möglich einzelne Logik Funktionen zu testen, oder?

Ich könnte mir automatische Teste eher bei embedded Systems vorstellen die aus einer großen Anzahl von Inputs eine recht kleine (testbare) Menge an Ausgaben erzeugen.

Oder habt ihr andere Erfahrungen mit automatischen Tests gesammelt?

Ma27

Fortgeschrittener

Beiträge: 157

Danksagungen: 133

  • Nachricht senden

12

Mittwoch, 31. Dezember 2014, 08:36

@Kliff,

wenn mal größere Änderungen entstehen, dann ist es oft sehr vorteilhaft, Tests zu haben, die dir erzählen, ob dein Feature tut oder nicht.
Es geht nicht darum eine 100%ige Test abdeckung zu kriegen, sondern darum Tests zu bauen, die wirklich testen.

Zitat

5. Obwohl alle Teste bestanden waren enthielt die Software offensichtliche Fehler. Eben solche die nicht durch die Tests abgedeckt wurden. Die Testes gaben so das trügerische Bild die Software wäre fehlerfrei, obwohl sie es nicht war.
hört sich nach simple unitTest abdeckung an. Wenn man das ganze Feature in einem durch testet (also auch mit DB und allem) dann wird sowas nicht passieren.

Oder was wäre, wenn du einige Code Stellen refaktorisierst und dann alles per Hand durchtesten müsstest. Da wäre es doch viel angenehmer, die ganzen Test Suites einmal durchlaufen zu lassen und zu sehen, dass es funktioniert

Slayer

Fortgeschrittener

Beiträge: 472

Danksagungen: 139

  • Nachricht senden

13

Mittwoch, 31. Dezember 2014, 09:24

Software ist nie fehlerfrei, sobald sie über ein "Hello World" hinausgeht! Das wird man selbst mit UnitTests nicht schaffen!

Wer aber ein Projekt länger betreibt und auch öfter einmal etwas ändert (was zwangsläufig passiert), der wird sehr froh über UnitTests sein. Und wenn es nur ein paar sind, die die Basisfunktionalität testen! In eXperinox haben wir z.B. Dutzende Missionen in unterschiedlichen Varianten. Diese immer alle händisch testen zu müssen, sobald man etwas an den Missionen ändert, wäre übel. Die Zeit, die wir hier in UnitTests investiert haben, macht sich in jedem Fall bezahlt. Nämlich letztendlich in Summe durch Zeitersparnis und auf jeden Fall auch stabileren Code.

Zudem habe ich durch UnitTests immer wieder einmal entdeckt, dass so manches Interface einer Klasse alles andere als gut ist. Denn beim Schreiben eines Tests beschäftigt man sich gerade mit den Interfaces/Methoden recht intensiv. Und wenn man z.B. für den Aufruf einer Methode zuviele Übergabe-Parameter initialisieren muss, kann das schon ein Zeichen für ein evtl. sinnvolles Refactoring sein. (Thema: Interface so schmal als möglich).

100% Test-Abdeckung ist aus meiner Sicht übrigens sinnfrei! Das kostet am Ende einfach zu viel Zeit und bringt eher wenig. Mein Anspruch wäre, etwa 80-90% Coverage zu erreichen - je nach Aufgaben einer Klasse kann ein anderer Wert sinnvoll sein.

Leider nehme auch ich mir viel zu wenig Zeit für UnitTests. Aber immer, wenn ich wieder ein paar Tests schreibe, stolpere ich über unsaubere Designs und auch Fehler, die schon lange versteckt im Code schlummern.

Have fun
Slayer
eXperinox - Browserspiel Science Fiction / Weltraum - "noXen macht Spaß!"
---
Austria Insiderinfo - Wandern im Salzburger Land

BlackScorp

Moderator

  • »BlackScorp« ist der Autor dieses Themas

Beiträge: 1 284

Wohnort: 127.0.0.1

Danksagungen: 568

  • Nachricht senden

14

Mittwoch, 31. Dezember 2014, 09:51

Zitat

1. Das Schreiben der Teste war sehr zeitaufwendig. Oft wurde für das
schreiben eines Test deutlich mehr Zeit verwendet als für das Feature an
sich. Teilweise das 4 Fache der Zeit.
Nun Tests schreiben ist ein Skill, dieses muss geübt sein, als du anfingst zu lernen wie man auf einem Fahrrad fährt, bist du sicherlich auch einige Male hingefallen. Selbst als du verstanden hast wie man das Gleichgewicht hält warst du sicherlich eine Zeitlang unsicher auf dem Fahrrad. Erst paar Monate/Jahre später hast du dich dann getraut auf der Straße zu Fahren. Ähnlich ist es mit den Tests. Wenn man paar Beispiele gesehen und man sich denkt, es verstanden zu haben, reicht es dennoch nicht. Man muss es üben. Man muss das Gespür dafür aufbauen was man Testen sollte.

Im TDD sagt man übrigens, sind die Tests kompliziert, so stimmt was nicht mit dem Code. Schwere Tests sind Code Smells.

Zitat

2. Oft sind triviale Test entstanden, die entweder immer bestanden waren oder eine sehr triviale Funktionen testeten.
Das hatte ich am Anfang auch, später habe ich aber festgestellt, dass JEDE Applikation eigentlich Trivial ist, besonders bei Webseiten. Man Ruft eine URL auf über POST/GET auf mit einigen Parametern, das wird verarbeitet und es gibt ein Ergebnis, dieses Ergebnis wird entweder durch json_encode oder einer Template engine ausgegeben. Alles ist dann Trivial

Zitat

3. Wenn ein Test nicht bestanden wurde, wurde gefühlt eher der Test
angepasst als das Programm. Da in den meisten Fällen der Test das
Problem war nicht die Funktion.
Das ist wieder ein Codesmell für Coupled Tests, man soll nur Teile Testen und nicht alles auf einmal. Man nennt es auch eine Single Assert Rule, damit ist nicht gemeint dass man nur einmal eine Assert Methode aufruft, sondern eher dass man nur ein Status der Anwendung abfragt.

Zitat

4. Durch automatische Tests wurden immer nur die Fehler abgefangen an
die man gedacht hat und die daher sowieso schon in der vorher
geschriebenen Funktion berücksichtigt wurden. Fehlerquellen die bei der
Funktion nicht berücksichtigt wurden, wurden so durch den Test auch
nicht berücksichtigt.
Dazu gibt es Code Coverage. Hat man nicht alles abgedeckt oder mit einem assert zu viel abgedeckt , so hat man die Tests falsch gemacht. Wenn man keine 100% Testcoverage hat dann weis man dass bestimmte Fälle noch nicht durch tests abgedekt sind.

Zitat

Meiner Meinung nach haben die Tests weder dazu geführt, dass besserer
Code entstanden ist, noch konnten sie sicherstellen dass die Software
fehlerfrei ist. Ich denke es wäre sinnvoller die Zeit ,die für schreiben
und ausführen der Tests draufgeht, darin zu investieren, sich Gedanken
über den Code und mögliche Fehlerquellen zu machen, oder die Software
manuell zu Testen.
Es kommt drauf an wie ihr die Sache angegangen seid. Wenn ihr Test Driven entwickelt, müsst ihr zuerst die Tests schreiben. Dann dürft ihr gerade mal so viel Code schreiben damit die Tests auch passen. http://de.slideshare.net/marcello.duarte…nsform-refactor hier kann man interessante Slideshares dazu sehen ab 19 wirds verständlich.

Es geht dort um eine Klasse die Arabische Zahlen in Römische Zahlen umwandelt. Wie man sehr schön dort sehen kann, kommt immer mehr logik in die Klasse hinzu mit weiteren Testcases. Der erste Test war, wenn eine 0 übergeben wird, so soll ein leerer String zurückkommen, also hat er, egal welchen Parameter einfach return ""; geschrieben. Die Logik wird nicht von Anfang an eingebaut, sondern mit den Tests.

Zitat

Ich kann mir allerdings automatische Teste bei Webseiten schwer
vorstellen. Das Ergebnis einer Anfrage ist ja meist ein dynamisches html
Dokument oder ein json Objekt welches von Daten in der Datenbank und
einer viel Zahl von Parametern abhängt. Wie kann ein automatischer Test
jetzt überprüfen ob die Antwort korrekt ist? Ob z.B. alle Informationen
richtig dargestellt werden? Es wäre doch nur möglich einzelne Logik
Funktionen zu testen, oder?
Wenn man sich strikt an das EVA Prinzip hällt und ja keine Logik in der Ausgabe einbaut. Sprich, man hat ein Response Objekt, während der Ausführung wird das Response objekt befüllt bzw werden die Variablen des Responseobjekts überschrieben, dann Braucht man nicht mehr das HTML zu Testen sondern das Response Objekt. Und dann wird es wirklich Trivial wenn du ein Objekt hast und einfach nur eigenschaften des Objekts abfragst ob es die Werte x/y/z hat.

Als Beispiel. Ich habe einige Logiken eingebaut in meinem Projekt, beim Besuch der Login/Registrierungsseite wird geschaut ob ich in der Session bereits ein Username steht, wenn ja so werde ich direkt zum Spiel weitergeleitet. Man soll sich nicht einloggen können, wenn man bereits eingeloggt ist.

Quellcode

1
2
3
4
5
6
7
8
9
10
11
12
13
14
public function testRedirectIfAlreadyLoggedInOnRegistrationPage()
{
     //Erstelle ein Request objekt
    $request = Request::create('/register');
    //Erstelle ein Fake Session objekt, füll es mit werten und übergebe es dem Request
    $session = $this->app['session'];
    $session->set('username', 'test');
    $request->setSession($session);
    /**
     * @var AuthResponse $response
     */
    $response = $this->app->handle($request);
    $this->assertSame(302, $response->getStatusCode()); //Das response objekt sollte ein Redirect Header haben
}


Wie es intern gehandelt wird, spiel für mich keine Rolle, an der Stelle interessiere ich mich nur für das Resultat. Wenn ich HTML Testen würde, so müsste ich ständig tests anpassen wenn sich der HTML Code ändert. Visuelle Tests mach ich im Grunde nie weil ich am ende ein Response Objekt ohne logik habe, ich sage dann nur noch in den div kommt die Eigenschaft des Objekts, in den nächsten Div die eigenschaft usw.. kaum ifs im HTML



Ich vergleiche immer wieder den Vorgang durch die Tests den Code zu schreiben, wie mit den Grafikern. Kein Grafiker fängt zeichnet sofort das fertige Bild. Es werden Hilfslinien gezeichnet und an den Hilfslinien orientiert sich dann der Grafiker. Ähnlich ist es mit den Tests, man schreibt nicht sofort eine fertige Klasse, man erstellt Tests und mit weitere Testcases wird der Code bearbeitet.
Qualität eines Codes misst man in WTF/Sekunde

15

Mittwoch, 31. Dezember 2014, 11:47

Das leidige Thema Test.

Das ist so kompliziert das ich, obwohl ich da ja nun schon ne Weile drüber nachdenke, keine Struktur finde die das mal vernünftig erklären könnte.

1. Wie entstehen Tests.

Das mag zum einen daran liegen das der Begriff "Test" für alles verwendet wird womit man seine Erwartungen gegen die Realität prüft. Und da jeder Programmierer, jede Programmiersprache und jede Software unterschiedlichste Erwartungen beim Programmierer weckt, gibt es auch die unterschiedlichsten Methoden um zu "Testen".

Eine Voraussetzung um überhaupt etwas testen zu können ist die Erwartung. Ein besseres Wort dafür ist die Anforderung, von einem Kunden definiert oder von einem selbst wenn man an seinem privaten Projekt arbeitet. Der Kunde hat irgendwo Anforderungen definiert und die Erwartung ist das das funktioniert.

In der Software-Entwicklung benutzt man dafür englische Begriffe und damit wird das ein Requirement, damit kann man dann auch bei google nach weiterführenden Infos suchen.

Typischerweise gibt es eine Reihe von Requirements die die Funktion der Software beschreiben. Sind alle Requierments erfüllt, ist die Software komplett. Die Erfüllung der Requirements wird über Test festgestellt. Dabei definiert die Formulierung der Requirements und deren Komplexität wie aufwändig der entsprechende Test wird. Es können zum Beispiel auch Requirements existieren die das Verhalten im Fehlerfall definieren, dann muss man in seinem Test den Fehlerfall erzeugen.

Requirements werden an vielen anderen Stellen in der Software-Entwicklung eingesetzt. Daher gilt für Requirements, das darin nur eine Eigenschaft/Verhalten definiert sein soll. Dadurch erhält man auch automatisch einfache Tests für die Requirements.

Alles was ich bisher gesagt habe gilt für die Spezifizierung einer Software, Application-Requirements. Wir befinden uns also im Moment auf der Ebene der Anwendung und der Anwendungstest. Dabei wird die konkrete Realisierung völlig ignoriert. Es ist vielmehr eine Anforderung an die Requirements, das diese keine Annahmen bezüglich der verwendeten Programmiersprache oder Ausführungsumgebung machen. Sie sind also nicht vom OS abhängig oder, im Falle von Web-Anwendungen, vom verwendeten Web-Server.

Der nächste Level wäre dann die Realisierung. Auch dafür kann man Requierments schreiben. Dort taucht dann das erstemal die Umgebung auf in der die Software funktionieren muss. Es wird eine Architktur und das Design der Software spezifiziert. Wie vorher auch werden hier Tests verwendet um die Requirements zu prüfen. Vielmehr neues gibt es hier nicht zu sagen.

Die Realisierung/Implementierung wird nicht durch Requirements beschrieben sondern durch die Module die man erzeugt und durch die verwendete Programmiersprachen. Um die Funktion nachzuweisen werden Unit-Tests verwendet. Für jede Funktion ein Test.

2. Verwendung von Tests

Tests sind der Nachweis über die Umsetzung der Anforderung. Wenn man für einen Kunden arbeitet und ein neues Release erstellt wird sollte man die Ergebnisse dieser Tests mit ausliefern, auch wenn einige Tests negativ gelaufen sind.
Wenn man in einem Team arbeitet hat man nicht zwingend alles im Blick. Auch dort helfen die Tests dabei festzustellen ob alle Anforderungen umgesetzt worden sind und funktionieren.

3. Anforderungen an Tests

Ein Test wird immer anhand der Requirements geschrieben, niemals anhand der Realisierung.
Ein Test wird niemals vom Entwickler der Software/Module was auch immer geschrieben. Wenn der Entwickler ein Requirement missverstanden hat würde der Test positiv ausfallen obwohl der Kunde was ganz anderes wollte.
Man muss nicht nur schauen ob alle Requirements einen Test besitzen, sondern ob das Requirement auch realisiert worden ist.

4. Alles andere was man dazu sagen kann

Test-Driven-Development verlangt vom Entwickler das schreiben von Tests für seine Module. Das ist zwar kostensparend, weil man nur den Entwickler bezahlt, aber widerspricht der Logik von Tests an sich.
Test-Driven-Development geht auch davon aus das der Entwickler keine Tests macht, seinen Code nicht auf Funktionalität prüft. Das mag in der Web-Entwickler Welt wohl so sein. Ich kenne in meinem Umfeld niemanden der blind seinen Code abliefert ohne einen so genannten "Entwickler-Test" zu machen.

Unit-Tests sind bei wirklich trivialen Funktionen relativ wertlos. Sie werden immer dann interessant wenn man mit Datentypen arbeitet bei denen nur eine Teilmenge der darstellbaren Werte genutzt wird. Das findet man im embedded Bereich täglich. Oft werden nur 12-Bit Zahlen verarbeitet. Da man aber trotzdem die Genauigkeit bei Berechnungen braucht wird das ganze dann mit bösen Rechentricks aufgepumpt. Jeder eingesparte Assemblerbefehl ist wertvoll.
Dort sind dann Unit-Tests auch für recht triviale Funktionen sinnvoll, da man dort prüfen muss ob die Berechnungen für einen definierten Wertebereich auch funktionieren. Da kann eine einfache Rechenoperation dazuführen das alle Kombinationen durchlaufen werden um sicherzustellen das das immer funktioniert.

Eine vernünftige Architektur/Design ist mehr Wert als jeder Test. Da die Tests nicht zwingend die Schwächen der Software aufzeigen können. Aber auch hier ist die Web-Entwicklergemeinde, und die findet man ja hier bei Web-Gamers, was besonderes.

1. Sind die architektonischen Variationen bei Web-Anwendungen dünn gesät.
2. Wird viel in Ein-Mann Teams gearbeitet.
3. Es wird kein Requirement Engineering betrieben.

So. Das wars.

BlackScorp

Moderator

  • »BlackScorp« ist der Autor dieses Themas

Beiträge: 1 284

Wohnort: 127.0.0.1

Danksagungen: 568

  • Nachricht senden

16

Mittwoch, 31. Dezember 2014, 12:05

Ja simbad,

die Webentwickler Welt unterscheidet sich noch deutlich von Hochsprachen. Das ist der Grund wieso es mittlerweile so viele Webentwickler gibt. Es reicht in der Webentwicklung irgendwas zusammen zu frickeln und es dann überteuert an den Kunden zu verkaufen. Es wird immer mit "keine Zeit" argumentiert, wobei in meisten Fällen es nicht an der Zeit hapert sondern an dem Know-How.

C++ ist zu kompliziert aber ich will Software Schreiben, also lerne ich PHP .. mittlerweile kann ich die ganzen Java/C# Entwickler verstehen, warum die denken dass PHP Entwickler nur Scriptkiddies sind.

In Hochsprachen wie C++/C# usw. benötigt man schon ein gewisses Grundwissen um damit arbeiten zu können. In Hochsprachen ist es eben öfters eine Anforderung Tests zu schreiben, in der Webentwicklung machen es nur die Wenigen, deswegen habe ich mir erhofft einigen einfach mal ins Gewissen zu reden und die zu motivieren, das automatisierte Testen einfach mal zu üben.
Qualität eines Codes misst man in WTF/Sekunde

17

Mittwoch, 31. Dezember 2014, 12:27

PHP ist eine hochsprache.
Immerhin ist sie mittlerweile sogar objektorientiert.
Es wird nicht dadurch besser das man die Methoden der anderen Hochsprachen ignoriert oder durch zweifelhafte Ideen ersetzt, die eigentlich alles noch viel schlimmer machen.

Aber sei es drum. Ich wollte nur mal meinen Senf dazugeben.

Kliff

Schüler

Beiträge: 68

Wohnort: Hannover

Danksagungen: 92

  • Nachricht senden

18

Freitag, 2. Januar 2015, 13:32

Hallo und frohes Neues!

@BlackScorp
Nach deiner Antwort verstehe ich nun mehr wie das mit dem Testen gemeint ist. Der Test soll nicht beweisen, dass die Software fehlerfrei ist, sonder nur das interne Funktion bei konkreten Eingaben auch die richtigen Ausgaben erzeugen, oder? Also eher ein Ist/Sollwert Vergleich. Das automatische Testen ist damit kein Tool um Fehler zu suchen, sonder eher eine Art Abnahmetest der die Funktion des Programms im normal Fall sicherstellt.

Es wird also nicht die Oberfläche (das html) getestet sondern nur das Objekt welches man der Template-Engine übergibt. Das mach für mich schon deutlich mehr Sinn. Allerdings blendet man dann natürlich Fehler, die in den Templates stecken, aus. Klar sollte in den Templates möglichst wenig Logik sein. Aber ein wenig ist ja doch immer drin.

In einigen Fällen (ein gutes Beispiel sind Missionen) könnte ich mir schon vorstellen, dass solche Teste praktisch sind. Trotzdem bin ich skeptisch ob es wirklich ein Gewinn ist sich die Arbeit zu machen und zu versuchen 100% Abdeckung zu erreichen.

Vielleicht werde ich mich bei Gelegenheit damit mehr beschäftigen.

BlackScorp

Moderator

  • »BlackScorp« ist der Autor dieses Themas

Beiträge: 1 284

Wohnort: 127.0.0.1

Danksagungen: 568

  • Nachricht senden

19

Freitag, 2. Januar 2015, 15:35

Du könntest die Tests auch als eine Art "Siegel" zu sehen. Im Mittelalter hatte man Briefe versiegelt, war das Siegel gebrochen, so ging man von der Annahme dass der Inhalt verfälscht war.

Die Tests setzten so gesehen ein Siegel auf bestimmte Funktion, wenn man nun etwas verändert, weis man ob man etwas kaputt gemacht hat oder nicht.

Als Beispiel. Du hast ein Game Entwickelt und es läuft schon mehrere Jahre. Nun fällt dir auf dass auf Grund von schlechten Datenbank Design, du Performance Schwierigkeiten hast. Nun veränderst du die Struktur. Worauf kann die Struktur eine Auswirkung haben? Was muss alles angepasst werden? Du drückst auf den "Play" Button in deiner IDE und siehst, Methode A/B/C geht nicht.

Mit den Tests, traust du dich Refactoring zu Betreiben, Fehler werden nicht vermieden, aber du kannst dir gewiss sein dass die Funktionen die keine Fehler haben, auch weiterhin funktionieren, egal wie viel du im Code verändert hast. Du hast sozusagen, Funktionen Versiegelt , schlägt der Test fehl (Siegel ist gebrochen) so stimmt etwas mit dem Inhalt nicht.

100% Abdeckung ist übrigens schnell erreicht da man ja sowieso viele unterschiedliche Fälle testet. Schwierig ist es sinnvolle 100%ige Abdeckung zu erreichen. Ich sehe es oft bei mir im Code, 100% Codecoverage, setze ich irgend ein Test auf @ignore hab ich dennoch 100% Codecoverage, d.h dieser Test ist nicht notwendig. Codecoverage ist eher ein Wegweiser. Dadurch dass man Rote stellen hat, sieht man welche Testcases man nicht beachtet hat.
Qualität eines Codes misst man in WTF/Sekunde

Social Bookmarks