Ankündigung

Einklappen
Keine Ankündigung bisher.

Was ist kompliziert an Tests und TDD?

Einklappen

Neue Werbung 2019

Einklappen
X
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • Was ist kompliziert an Tests und TDD?

    Hallo PHP Entwickler,

    viele wissen ja dass automatisierte Tests wichtig sind dennoch wird es ja oft vermieden.

    Ich möchte irgendwann mal ein Video zu dem Thema machen aber ich kann es aktuell nicht verstehen wieso es so schwer fällt. Deshalb dachte, ich Brainstorme mal hier mit anderen Entwicklern vielleicht werde ich ein wenig aufgeklärt und kann es dann besser nachvollziehen.

    Ich habe mal einige gefragt was ich denn so programmieren sollte mit TDD und mir ist dabei aufgefallen dass ich antworten bekam wie "irgnedwas-System" deshalb stelle ich eine These auf dass die Entwickler irgendwie denken dass beim Testen alles auf ein mal irgendwie getestet werden soll.

    Ich habe dann darauf hin gesagt dass ein "System" im Grunde eine Zusammensetzung von Formularen und Listen/Tabellen ist und im Grunde musst du entweder ein Formular Valdieren und Daten abspeichern oder eine Liste/Tabelle mit Daten anzeigen. Solche fälle lassen sich aber wunderbar Automatisiert Testen. Ein Formular ist auch meistens in Gruppen aufgeteilt weil in der GUI will man ja auch eine Übersicht aufbauen.

    Eine weitere These ist. Die Entwickler versucht einige Dinge "Magisch" umzusetzen wegen Wiederverwendbarkeit und erdenkt sich dadurch Maximal komplexe UseCases für den Fall der Fälle. "Es könnte ja sein" in vielen Fällen trifft das aber alles eh nicht zu und er hat sich dadurch die Möglichkeit der Tests kaputt gemacht.

    Wie ist eure Meinung? Wenn ihr nicht testet was ist der Grund? Also es an die bezogen die wissen was tests sind und wissen wie man diese schreibt.

    Vielleicht bin ich zu naiv oder ich hatte noch nie so komplexe Projekte wo ich mir dachte "Boah das kann ich aber nicht testen". Wäre cool mal von anderen Entwickler konkret zu hören wo das Problem ist statt sich irgendwelche Problemszenarien auszudenken

    VIele Grüße
    apt-get install npm -> npm install -g bower -> bower install <package> YOLO [URL]https://www.paypal.me/BlackScorp[/URL] | Mein Youtube PHP Kanal: [url]https://www.youtube.com/c/VitalijMik[/url]

  • #2
    - Anforderungen werden nicht klar definiert und/oder nicht dokumentiert, es ist also nicht klar was überhaupt getestet werden soll
    - zusätzlicher Aufwand in der Einarbeitung und Einführung
    - Regelmäßige Anpassungen der Tests an geänderte Anforderungen
    - Testumgebung in der geeignete Daten vorhanden sind

    klar kann man das alles testen, man kann Testbedingungen herstellen, das Teil soll am Ende ja was können, aber das ist halt Aufwand (der sich lohnt!) den viele erstmal scheuen (wobei ich bisher keinen Entwickler getroffen habe der dagegen ist, eher viele die sich genau das wünschen).
    [I]You know, my wife sometimes looks at me strangely. „Duncan“, she says, „there's more to life than Solaris“. Frankly, it's like she speaks another language. I mean, the words make sense individually, but put them together and it's complete nonsense.[/I]

    Kommentar


    • #3
      Danke

      Zitat von chorn Beitrag anzeigen
      (wobei ich bisher keinen Entwickler getroffen habe der dagegen ist, eher viele die sich genau das wünschen).
      Ich ja auch und desswegen frage ich mich halt die ganze Zeit wo das Problem ist. Wegen unklaren Anforderungen, wenn man doch die Solid Regeln beachtet, kann man ja zum Beispiel erst ein Code schreiben und dann die Tests oben drauf legen wenn die Anforderungen klarer geworden sind.

      Bisher konnte ich nur beobachte dass es meistens daran lag weil jeder dachte seine Anforderungen sind sehr "kompliziert"
      apt-get install npm -> npm install -g bower -> bower install <package> YOLO [URL]https://www.paypal.me/BlackScorp[/URL] | Mein Youtube PHP Kanal: [url]https://www.youtube.com/c/VitalijMik[/url]

      Kommentar


      • #4
        Mein TDD ist ja etwas abseits vom Standard. Ich verweise daher nur auf diesen schon etwas älteren Beitrag Test und Präsentation für PHP.

        Kommentar


        • #5
          BlackScorp hört sich so an, als wenn du aus der Sicht des Entwicklers sprichst. Wenn du selbstständig bist und machen kannst was du willst und dein Budget dem Kunden so verkaufen kannst - super. Wenn nicht: schlecht für alle.
          [I]You know, my wife sometimes looks at me strangely. „Duncan“, she says, „there's more to life than Solaris“. Frankly, it's like she speaks another language. I mean, the words make sense individually, but put them together and it's complete nonsense.[/I]

          Kommentar


          • #6
            Zitat von chorn Beitrag anzeigen
            BlackScorp hört sich so an, als wenn du aus der Sicht des Entwicklers sprichst. Wenn du selbstständig bist und machen kannst was du willst und dein Budget dem Kunden so verkaufen kannst - super. Wenn nicht: schlecht für alle.
            Ist auch ein Interessantes Argument, aber was ist mit Bugs beheben? Werden die extra abgerechnet? Was ist mit update auf von alter Software? Wird das extra abgerechnet? Ich frage das halt weil ich keinen Unterschied sehe ob ich jetzt vorher paar Tests geniere oder nicht, Zeitlich konnte ich keinen Unterschied feststellen. Das Manuelle Testen und überprüfen dauert auch lange.
            apt-get install npm -> npm install -g bower -> bower install <package> YOLO [URL]https://www.paypal.me/BlackScorp[/URL] | Mein Youtube PHP Kanal: [url]https://www.youtube.com/c/VitalijMik[/url]

            Kommentar


            • #7
              Ich muss auch gestehen, ich schreibe selten Test. Der einzige Grund ist die Zeit. Den die Tests zu schreiben benötigt echt viel Zeit.

              Kommentar


              • #8
                Zitat von strub Beitrag anzeigen
                Ich muss auch gestehen, ich schreibe selten Test. Der einzige Grund ist die Zeit. Den die Tests zu schreiben benötigt echt viel Zeit.
                ja ich glaube das ist der meiste Grund dafür. Ich frage mich halt ob das einfach nur gefühlt ist weil du ja irgendwas schreibst und es sich auf der Webseite ja nichts verändert. Also dass man denkt, weil es sich nichts verändert würde man viel Zeit dafür Aufbrigen.

                Würde man debugging Zeit oder Brainstorming Zeiten mit Kollegen irgendwie notieren, wäre vielleicht da eine andere Denkensweise.

                Ich habe das zum beispiel beim einsetzen der Pomodoro Technik gesehen dass ich es nie schaffe ein Bug innerhalb der 25 Minuten zu reproduzieren ohne der tests.

                Aber man kann schon ein Video zu diesen aufgelisteten Gründen machen. Ich habe halt generell dass man mehr nach Bauchgefühl arbeitet und man sich oft nicht traut in die Richtung zu gehen weil es ungewohnt ist.
                apt-get install npm -> npm install -g bower -> bower install <package> YOLO [URL]https://www.paypal.me/BlackScorp[/URL] | Mein Youtube PHP Kanal: [url]https://www.youtube.com/c/VitalijMik[/url]

                Kommentar


                • #9
                  Klar, wenn du schon Leute hast zum testen, und die dann auch rudimentäre Programmierkenntnisse haben um Tests zu schreiben, und deine Software neu entwickelt wird, und das auch noch im Budget ist - win. Aber die Kette bricht meiner Erfahrung nach ziemlich schnell zusammen. Alte Software nachzudokumentieren und nachzutesten und die ganzen Informationen aus den Köpfen der Leute zu bekommen, was denn "richtig" bedeutet kann halt zu einem riesen Akt werden, vor allem wenn Tagesgeschäft anliegt. Dann hast du auch seperation of concerns: Die Programmmierer können programmieren und die Fachleute kennen die richtigen Daten - die beiden Gruppen musst du dann irgendwie zusammenführen. Also ich spreche jetzt von 100+ Personen.

                  Ist jetzt sicher speziell und nur ein Problemkatalog. Ist alles lösbar, wenn alle mitmachen - am Ende entscheidet halt der dem die Firma gehört. Ich hab da schon positive und negative Erfahrungen gemacht, am Ende braucht man um sowas durchzusetzen sicher auch ein gewisses Verhandlungsgeschick.
                  [I]You know, my wife sometimes looks at me strangely. „Duncan“, she says, „there's more to life than Solaris“. Frankly, it's like she speaks another language. I mean, the words make sense individually, but put them together and it's complete nonsense.[/I]

                  Kommentar


                  • #10
                    Zitat von strub Beitrag anzeigen
                    Ich muss auch gestehen, ich schreibe selten Test. Der einzige Grund ist die Zeit. Den die Tests zu schreiben benötigt echt viel Zeit.
                    Ich schreibe Tests fast nur für Klassen und Funktionen.

                    Ein Problem dabei ist man muss sich zwingen mit dem Schreiben des Tests in einer sehr frühen Entwicklungsphase zu beginnen um dann den Test parallel mit jeden Entwicklungsschritt anzupassen. Wird dann nach jeden Schritt der Test ausgeführt werden Fehler/Bugs sehr schnell erkannt und können mit wenig Aufwand behoben werden. Das spart letztlich Zeit.

                    Werden die Tests erst im Nachgang geschrieben, wird dies sehr zeitaufwendig und zum Teil auch unmöglich. Werden mit den Test dann noch Fehler festgestellt ist das Beheben oft auch noch mal mit mit viel Zeit verbunden.

                    chorn Nach meiner Erfahrung sollte der Entwickler den Test selbst parallel zur Entwicklung schreiben und auch stetig nutzen. Das bringt echte Zeiteinsparung.

                    ---
                    Den/die Tests komplett vorab zu schreiben halte ich für eine praxisferne Theorie.

                    Kommentar


                    • #11
                      Zitat von jspit Beitrag anzeigen

                      Den/die Tests komplett vorab zu schreiben halte ich für eine praxisferne Theorie.
                      Findest du? Wenn man ein Projekt soweit abstrahiert dass es im Grunde nur darum geht ein Formular zu Validieren und abzuspeichern mit eventuellen event Triggern, sieht dann plötzlich alles anders aus. Ich kann mir echt nicht vorstellen was für ein Feature man nicht testen könnte. Also mit Test Driven Entwicklung. Vielleicht hast du ein Beispiel im Sinne?
                      apt-get install npm -> npm install -g bower -> bower install <package> YOLO [URL]https://www.paypal.me/BlackScorp[/URL] | Mein Youtube PHP Kanal: [url]https://www.youtube.com/c/VitalijMik[/url]

                      Kommentar


                      • #12
                        Ich hatte mit der Bemerkung schon eine etwas umfangreichere Klasse im Auge. Als Beispiel mal die DateTime-Erweiterung dt.
                        Sicher kann ein Projekt immer in mehrere kleine Stücke gesplittet werden die dann isoliert getestet werden können.
                        Dafür müssen aber Anforderungen und Umfang des Projektes zu 100% feststehen. Das habe ich jedoch noch nie erlebt.
                        Viele Klassen so auch meine unterliegen einer permanenten Weiterentwicklung zum Teil über mehrere Jahre.
                        Und der Test muss mit dieser Entwicklung mitwachsen und unterliegt somit auch einer stetigen Veränderung.

                        Kommentar


                        • #13
                          Zitat von jspit Beitrag anzeigen
                          Ich hatte mit der Bemerkung schon eine etwas umfangreichere Klasse im Auge. Als Beispiel mal die DateTime-Erweiterung dt.
                          So eine Klasse ließe sich wunderbar testen. Ich habe in der Klasse einige else und elseif gesehen, ich denke wenn man ein wenig die Logik negieren würde und noch weitere private Methoden anlegen würde, würde die Klasse halb so wild aussehen.
                          Zitat von jspit Beitrag anzeigen
                          Sicher kann ein Projekt immer in mehrere kleine Stücke gesplittet werden die dann isoliert getestet werden können.
                          Dafür müssen aber Anforderungen und Umfang des Projektes zu 100% feststehen. Das habe ich jedoch noch nie erlebt.
                          Ich habe das auch nicht gesehen dass irgendwas zu 100% Stand,aber bisher wusste ich halt immer was externe Abhängigkeit ist und was die Konkrete Logik eines Projektes ist. Und meistens war mir nicht klar wie etwas in dem CMS/Framework umgesetzt werden soll und nicht das feature an sich. Ich glaube dennoch man kann so entwickeln dass die externen Dependencies ersetzbar sind und somit bleibt die eigentliche Logik sehr klein. Dadurch tut es nicht weh auch die Klasse komplett zu verwerfen fall die Anforderungen sich doch geändert haben.

                          Zitat von jspit Beitrag anzeigen
                          Viele Klassen so auch meine unterliegen einer permanenten Weiterentwicklung zum Teil über mehrere Jahre.
                          Und der Test muss mit dieser Entwicklung mitwachsen und unterliegt somit auch einer stetigen Veränderung.
                          Ja genau aber genau deshalb sollte man doch tests haben, woher willst du wissen, wenn du etwas verändert hast dass nicht anderes betroffen wurde? Nur du als hauptentwickler kannst das erahnen, aber wenn ein 3er Dazukommt der wird doch keine Ahnung haben. In einem Unternehmen kommen und gehen Entwickler, die erweitern auch deine eigene Codebasis und natürlich verändert sich ständig irgendwas aber dauert es echt so lange die Tests anzupassen?
                          apt-get install npm -> npm install -g bower -> bower install <package> YOLO [URL]https://www.paypal.me/BlackScorp[/URL] | Mein Youtube PHP Kanal: [url]https://www.youtube.com/c/VitalijMik[/url]

                          Kommentar


                          • #14
                            Ich denke wir liegen mit unseren Meinungen gar nicht soweit auseinander. Du verstehst meine Bemerkung
                            Den/die Tests komplett vorab zu schreiben halte ich für eine praxisferne Theorie.
                            falsch. Die Betonung liegt auf vorab. Oder anders formuliert den Test vorher ohne die Klasse zu haben komplett fertig zu schreiben halte ich für eine praxisferne Theorie.

                            Und klar lässt sich so eine Klasse wunderbar testen. Hab ich ja auch gemacht nur eben mit anderen Werkzeugen.

                            Ich habe in der Klasse einige else und elseif gesehen, ich denke wenn man ein wenig die Logik negieren würde und noch weitere private Methoden anlegen würde, würde die Klasse halb so wild aussehen.
                            Damit bringst du ein Grund mit ins Spiel warum Tests und TDD kompliziert werden können. Man muss mehr oder weniger beim Schreiben der Klasse die Testbarkeit des Codes berücksichtigen.
                            Ich bin kein Freund davon den Code nur auf Grund einer guten Testbarkeit zu zerstückeln.

                            Mitunter müssen jedoch an bestimmten Stellen protected Methoden implementiert werden damit die Klasse überhaupt testbar wird.
                            Eine solchen Fall hatte ich bei meiner Autoloader-Klasse. Was üblicherweise mit einem simplen require 'filename' getan ist wurde hier in eine Methode gepackt, damit diese für den Test überschrieben werden kann um das Filesystem zu "mocken".

                            Kommentar


                            • #15
                              Tests sollten gegen das öffentliche Interface einer Klasse gemacht, Wenn ein Test auf interne Variablen oder interne Methoden einer Klasse zugreifen muss, stinkt etwas.

                              Im Falle einer Autoloader-Klässe müsste man ja nur mit class_exists() testen, ob die gewünschte Klasse geladen worden ist. Wenn ja: Autoloader funktioniert. Wenn nein, Autoloader funktioniert nicht. Mehr interessiert einen Test ja nicht.

                              Beim TDD geht es darum, dass eine Klasse so programmiert wird, dass sie ihre Aufgabe erfüllt. Der Klasse selber kann es vollkommen egal sein, ob für sie ein Test existiert oder nicht. Sie muss sich nur und das zuvor definierte Interface halten.

                              Kommentar

                              Lädt...
                              X