Gibt es Entwickler, die nicht testen?

Java-Forum Allgemeine Themen
1

Ich höre ab und zu mal, dass es Entwickler gibt (geben soll), die nicht testen. Aber kann es das geben?

Meine Hypothese ist, dass **jeder **Entwickler testet - aber halt nicht unbedingt automatisiert.
OK, nehmen wir z.B. an, ich hätte das hier geschrieben und bin mir sicher, dass es funktioniert

        int max = Integer.MIN_VALUE;
        for (int i = 1, size = array.length; i < size ; i++) {
            int current = array**;
            if(current > max) max = current;
        }
        return max;
    }

Ok, was macht ein Entwickler, der (angeblich) nicht testet? Der wird diese Funktion, **bestimmt **wenigstens mal
mit ein paar Eingaben füttern, z.B.:

		System.out.println(findMax(new int[] {1, 2, 3}));
		System.out.println(findMax(new int[] {1, 4, 3}));
		System.out.println(findMax(new int[] {7, 2, 3})); // ups, baaam!
	}

Ich teste also meinen Code manuell und finde, dass mein Programm Müll macht, wenn das erste Element das größte ist.
Jetzt untersuche ich meinen Code und finde den Fehler und bereinige ihn.

Das ist der Vorgang des manuellen Testen, da ich die main wieder lösche und so keine Regressions-Test habe.

Kann mir irgendjemand bestätigen, dass es Entwickler gibt, die solche [ähnliche] Sachen nicht (wenigstens) manuell testen?
Ich würde nämlich sagen, dass es diese nicht gibt. (Ich meine nicht eine Funktion/Code den jemand 1000x mal schon geschrieben hat und auswendig weiß).

Zudem kommen manuelle Tests schnell an ihre Grenzen.

Ansonsten ist das nicht-verwenden von automatisierten Tests wohl eine eine falsche Einstellung (vgl. Amateur zu professionellem Entwickler => der Profi setzt
Tools ein, während der Amateur eher so vor sich hin entwickelt und sich nie sicher sein kann [nicht 100% das kann auch nicht der Profi], dass seine Software funktioniert).

2

Kann mir irgendjemand bestätigen, dass es Entwickler gibt, die solche [ähnliche] Sachen nicht (wenigstens) manuell testen?

Irgendwo sitzt ganz bestimmt ein Knilch und testet nicht. Nicht umsonst gibt’s den Spruch:

If it compiles, ship it

Aber normal ist das nicht.

3

[QUOTE=Curiosity]Meine Hypothese ist, dass **jeder **Entwickler testet - aber halt nicht unbedingt automatisiert.
[/QUOTE]
Sehe das auch so, der Grossteil “testet” auf die eine oder andere Art.
Rein manuelles testen ist IMHO Zeitverschwendung und leisten nicht das, was automatisierte Tests leisten koennen.

4

Es kann aber sein, dass automatisiertes Testen sich nicht unbedingt auszahlt, z.B. wenn das Tool zu klein ist und mit einem manuellen Test alles abgecheckt ist, was zudem schneller sein kann als das Implementieren von automatisierten Tests. Ich habe vor kurzem auf heise.de diesen Artikel gelesen und muss sagen, das stimmt. Gerade wenn ein Projekt am Anfang steht, können viel zu schnell und zu viele Änderungen stattfinden oder das Projekt eine völlig andere Richtung einschlagen muss. Das automatisiert zu testen ist völlige Zeitverschwendung, weil die Tests alle umgeschrieben oder sogar verworfen werden müssen. Also automatisierte Tests sind in Anbetracht des Fortschritts eines Projektes sinnvoll, aber nicht das Nonplusultra. Köpfchen ist gefragt :wink: Aber testen wird jeder irgendwie. Spätestens das Ausführen der Anwendung ist dann auch ein Test und ich bezweifle, dass irgendjemand irgendwas runtertippt, kompiliert und sofort weiter gibt. Anfänger nicht, Fortgeschrittene nicht und professionelle Entwickler schon gar nicht.

5

Ich frag mich immer wer mit dem Schwachsinn angefangen hat zu meinen mit automatischen Tests habe mit volle Sicherheit und ist frei von Denken…

Ansonsten bin ich persoenlich solche Diskussionen leid. Wer meint er muesse nicht automatisch Testen, soll das tun. Ist nicht mein Projekt…

6

Ich finde den heise Artikel zum Thema testen wirklich nicht gut, das ist nix anderes als ein Versuch die bisherige (veraltete) Praxis zu rechtfertigen…

Automatisierte Tests die man erst schreibt nachdem der Prodcode fertig ist sind die Wurzel des Uebels, nicht dessen Loesung oder gar ein „guter Weg“… diese Tests sind immer schlecht wartbar, schwer zu schreiben und wenn die Zeit knapp wird (zB. weil man Bugs sucht die man mit TDD haette vermeiden koennen) fallen die ueber Bord, alles in allem der schlechteste Weg um automatisierte Tests zu schreiben IME.

Um es mal ganz radikal auszudruecken:
Alles ausser Testgetrieben ist nicht Zeitgemaess.

Ja ich weiss, eine sehr starke Behauptung und eine sehr radikale Position, aber polarisiernde Aussagen sind gut um eine Diskussion zu starten :wink:

Wenn man sowieso testet, naemlich manuell, dann muss man doch einsehen dass diese Tests spaeter durch automatisierte Tests ersetzt werden sollen und schon so gesheen ist das Zeitverschwendung, ganz zu schweigen von der Qualitaet des Codes und damit auch des Produktes.

7

Du scheinst an noch nicht sehr vielen Projekten gearbeitet zu haben. Es gibt genug Gründe auf Tests zu verzichten, gerade für Professionelle Entwickler, wobei nicht alle Gründe Tests wegzulassen unbedingt gerechtfertigt sind.

Zum Einen steht nur ein begrenztes Budget zur Verfügung stehen und wenn der Kunde sich entscheidet, dass ihm mehr Features lieber sind als weniger Features, die dafür besser funktionieren, dann wird das so gemacht.

Ein anderes Problem könnte sein, dass es viel zu aufwendig ist eine Test-Suite zu implementieren. Wenn die Erzeugung von Testfällen und -daten so kompliziert ist, dass man schon wieder Tests benötigt um die Korrektheit der Test-Suite zu testen, dann kann das durchaus ein Grund sein auf manuelle Tests auszuweichen. Wobei in dem Fall sich die Frage stellen dürfte ob man überhaupt noch manuell testen kann.

GUI Tests sind auch so eine Sache, das wird sehr schnell sehr aufwendig wenn das automatisiert erledigt werden soll. Und ob das GUI für den Anwender am Ende überhaupt benutzbar ist wird dabei in der Regel auch nicht getestet.

Bei der Einarbeitung in eine neue Software bzw. ein neues Framework ist die Tendenz auch groß auf automatisiertes Testen zu verzichten. Wenn man nicht weiß wie man etwas richtig aufbaut und deshalb viele Refactorings von Nöten sind, dann sind automatisierte Tests nur hinderlich.

Zuletzt fällt mir noch Software ein, die sehr low level ist. Was willst du testen wenn du Hardware ansteuerst, die Spezifikation der Hardware selbst? Da bringen Tests so gut wie gar nichts. Zumahl sich Spezifikationen für Hardware sowieso ständig ändern, da willst du auch keine Tests haben, die du ständig anpassen musst.

In der Praxis setze ich immer mehr auf code review, da wird das Problem minimiert, dass man selbst auch gar nicht in der Lage ist für alles mögliche Tests zu schreiben, einfach weil einem die Testfälle gar nicht erst in den Sinn kommen.

8

[QUOTE=maki]Ich finde den heise Artikel zum Thema testen wirklich nicht gut, das ist nix anderes als ein Versuch die bisherige (veraltete) Praxis zu rechtfertigen…

Automatisierte Tests die man erst schreibt nachdem der Prodcode fertig ist sind die Wurzel des Uebels, nicht dessen Loesung oder gar ein „guter Weg“… diese Tests sind immer schlecht wartbar, schwer zu schreiben und wenn die Zeit knapp wird (zB. weil man Bugs sucht die man mit TDD haette vermeiden koennen) fallen die ueber Bord, alles in allem der schlechteste Weg um automatisierte Tests zu schreiben IME.

Um es mal ganz radikal auszudruecken:
Alles ausser Testgetrieben ist nicht Zeitgemaess.

Ja ich weiss, eine sehr starke Behauptung und eine sehr radikale Position, aber polarisiernde Aussagen sind gut um eine Diskussion zu starten :wink:

Wenn man sowieso testet, naemlich manuell, dann muss man doch einsehen dass diese Tests spaeter durch automatisierte Tests ersetzt werden sollen und schon so gesheen ist das Zeitverschwendung, ganz zu schweigen von der Qualitaet des Codes und damit auch des Produktes.[/QUOTE]

Eigentlich stimme ich dir ja zu, jedenfalls im professionellen Bereich (wovon wir hier erstmal ausgehen können). Aber dass sich zu Hause ein Hobby-Bastler mit automatisierten Tests beschäftigt, kann man wohl kaum als gegeben betrachten und bei zu kleinen Tools ist das sicherlich auch nicht unbedingt nötig. Bei irgendwelchen kleinen temporären Tools oder Skripten, wie z.B. nem Code-Generator, den man gerade braucht, weil man keine Lust hat händisch 1000 Klassen anzupassen oder sowas würde ich auch keine Tests schreiben. Fünf Minuten Skript tippen und dafür vielleicht Stunden lang Tests schreiben nur um etwas zu testen, was man nach vielleicht einer Minute auch so gesehen hätte, weil das Skript Mist baut? Sowas sind natürlich die Ausnahmen, ich denke da sind wir uns einig. Automatisiert testen ja, aber es nicht als Religion ansehen … Da gibt es auch andere Mittel, die bei einem bestimmten Anwendungsfall schneller zum Ziel führen können.

9

Ich denke auch. Der wird aber nicht lange Programmierer bleiben (denke ich). Gehen wir mal von einem normal denkenden Mensch aus.
OK, danke. Man kann also sagen, dass Testen inhärenter Bestandteil des Entwickelns ist. Auch wenn einige damit kokettieren nicht zu testen.
Jeder testet (auch wenn nur manuell im Sinne von [„Macht mein Programm das, was ich mir gedacht habe“]). Alles andere ist Blödsinn.

Wie Tool-unterstützt wir das machen ist dann eine ganz andere Frage.
@Akeshihiro : Danke für den Link. Zum anderen Inhalt deines Posts: Hier scheiden sich die Geister:

  • Wird der Prototyp von den Kunden angenommen (sich seine Daseinsberechtigung gezeigt hat) wird dieser Prototyp nicht weggeschmissen.
  • Wieso man einen Prototyp nicht wegschmeissthttp://www.joelonsoftware.com/articles/fog0000000069.html
  • Danach hat meinen einen Prototyp, der aus einem Klumpen Schlamperei/Unordnung/Technischer Schuld besteht.
  • Zudem wird doch in Agilen Projekten (und nicht nur dort) angeraten, so früh wie möglich zu testen, damit Tests Feedback über die Struktur und das Design der Software geben, sowie durch frühzeitige Regressions-test die Qualität der Software hinsichtlich Funktionalität und technischer Schuld erhöhen.
10

natuerlich interessiert es kein Schwein was Hacker-Joe in seinem Keller macht ausser vielleicht Hacker-Joe. Und da kann er natuerlich auch mit den Fuessen schreiben oder gleichzeitig Twilight gucken - is wurscht.

Bzgl. Religion - Zaehneputzen ist auch keine Religion, aber ich will mich mit Leuten nicht umgeben die es nicht machen - HackerJoe allein im Keller wiederum kann es natuerlich auch lassen

11

[QUOTE=Antoras]Du scheinst an noch nicht sehr vielen Projekten gearbeitet zu haben. Es gibt genug Gründe auf Tests zu verzichten, gerade für Professionelle Entwickler, wobei nicht alle Gründe Tests wegzulassen unbedingt gerechtfertigt sind.
[/quote]
Die Grunde dich aus persoenlicher Erfahrung kenne:
Mangelnde Erfahrung der Entwickler.
Alles andere waren nur Ausreden IME.

Zum Einen steht nur ein begrenztes Budget zur Verfügung stehen und wenn der Kunde sich entscheidet, dass ihm mehr Features lieber sind als weniger Features, die dafür besser funktionieren, dann wird das so gemacht.

Auch dafuer kann man automatisierte Tests nutzen, und genau da spielt TDD einige seiner staerken aus.
Ich kann naemlich ganz schnell ausprobieren was passiert wenn ich Feature XYZ aktiviere bzw. deaktiviere, dasselbe gilt fuers refactoring.

Ein anderes Problem könnte sein, dass es viel zu aufwendig ist eine Test-Suite zu implementieren. Wenn die Erzeugung von Testfällen und -daten so kompliziert ist, dass man schon wieder Tests benötigt um die Korrektheit der Test-Suite zu testen, dann kann das durchaus ein Grund sein auf manuelle Tests auszuweichen. Wobei in dem Fall sich die Frage stellen dürfte ob man überhaupt noch manuell testen kann.

Nun, nicht-testbaren Code zu schreiben ist ein Verbrechen IMHO, schwer testbaren Code zu schreiben zumindest eine Ordnungswidrigkeit.
Wenn ich meine Tests vor dem Prodcode schreibe, kann das gar nicht passieren.

GUI Tests sind auch so eine Sache, das wird sehr schnell sehr aufwendig wenn das automatisiert erledigt werden soll. Und ob das GUI für den Anwender am Ende überhaupt benutzbar ist wird dabei in der Regel auch nicht getestet.

GUI tests sind in der Tat komplex und aufwaendig, stellen aber nur einen Bruchteil einer automatisierten Testsuite dar.

Bei der Einarbeitung in eine neue Software bzw. ein neues Framework ist die Tendenz auch groß auf automatisiertes Testen zu verzichten. Wenn man nicht weiß wie man etwas richtig aufbaut und deshalb viele Refactorings von Nöten sind, dann sind automatisierte Tests nur hinderlich.

Auch hier hast du unrecht.
Sog. „learning tests“ zu schreiben um neue APIs/Frameworks zu erlernen hat immense Vorteile („sind meine Annahmen wirklich richtig?“, „habe ich das ganze richtig verstanden?“), vor allem auch beim Update der APIs/Frameworks.
Ansonsten wuerde man halt Programme zum testen schreiben anstatt autom. Tests, nicht wahr? :wink:

Zuletzt fällt mir noch Software ein, die sehr low level ist. Was willst du testen wenn du Hardware ansteuerst, die Spezifikation der Hardware selbst? Da bringen Tests so gut wie gar nichts. Zumahl sich Spezifikationen für Hardware sowieso ständig ändern, da willst du auch keine Tests haben, die du ständig anpassen musst.

Test muessen flexibel und aenderbar sein.
Ansonsten ist das mit dem HW testen richtig, aber wie oft hat man sowas schon?

In der Praxis setze ich immer mehr auf code review, da wird das Problem minimiert, dass man selbst auch gar nicht in der Lage ist für alles mögliche Tests zu schreiben, einfach weil einem die Testfälle gar nicht erst in den Sinn kommen.

Codereviews sind wichtig, bringen aber nix wenn der Kollege auch keine Ahnung hat.
Anders ausgedrueckt, wenn das gemeinsame Wertesystem nicht so dollle ist, bruingt es gar nix wenn man sich einig ist.

12

ach wie gut das @maki noch weiterkaempft :slight_smile:

13

Naja, uns „fehlen“ hier noch ein paar Dikussionen zu klassischen Themen wie autom. Tests, Singletons und DI… einmal sagen reicht dann mir dann aber schon :wink:

14

Man kann sich über alles streiten … äh … diskutieren … :smiley:

15

Hehhe… schon klar, soll ja vernuenftig bleiben :slight_smile:

Mir ist klar dass viele Leute das anders sehen, habe aber noch nie jemanden getroffen der TDD „gemeistert“ hat der eine andere Einselluing zu autom. Tests hatte.
Oft habe ich so Aussagen wie „extreme Programming doesn’t work, because i tried it and failed…“ gehoert.

Ja, testgetrieben ist nicht einfach Anfangs, die Lernkurve ist Steil:
man muss gute Tests schreiben koennen, ein Unitest- und Mockingframework gut beherrschen, dazu noch etwas ueber Design wissen, gut Refactoren koennen etc. pp. , vor allem muss man aber seine Gewohnheiten bekaempfen, „Ich habe schon eine Loesung im Kopf“ ist leider die falsche Einstellung, die erste Frage sollte immer lauten „Wie koennte man das testen?“.
Der letzte Punkt ist wirklich der schwierigste IME, weil es eben gegen die bisherigen Gewohnheiten geht.

16

[QUOTE=maki]Hehhe… schon klar, soll ja vernuenftig bleiben :slight_smile:

Mir ist klar dass viele Leute das anders sehen, habe aber noch nie jemanden getroffen der TDD „gemeistert“ hat der eine andere Einselluing zu autom. Tests hatte.
Oft habe ich so Aussagen wie „extreme Programming doesn’t work, because i tried it and failed…“ gehoert.

Ja, testgetrieben ist nicht einfach Anfangs, die Lernkurve ist Steil:
man muss gute Tests schreiben koennen, ein Unitest- und Mockingframework gut beherrschen, dazu noch etwas ueber Design wissen, gut Refactoren koennen etc. pp. , vor allem muss man aber seine Gewohnheiten bekaempfen, „Ich habe schon eine Loesung im Kopf“ ist leider die falsche Einstellung, die erste Frage sollte immer lauten „Wie koennte man das testen?“.
Der letzte Punkt ist wirklich der schwierigste IME, weil es eben gegen die bisherigen Gewohnheiten geht.[/QUOTE]

Vielen Dank für deine Einblicke und Erfahrung. => Gold Wert.

17

Zur ursprünglichen Frage: Zwischen “garnicht” testen und “alles” testen gibts ja noch einiges. Dass ein Entwickler wirklich überhaupt rein garnichts testet, das glaube ich einfach nicht. Man führt es ja zumindest einmal aus um wenigstens zu schauen, ob es läuft ohne zu “knallen”. Manche Entwickler schreiben dann wie du sagtest eine main-Methode (o.Ä.) mit ein paar Aufrufen. Und wiederum andere schreiben ein paar Tests. Und dann gibts eben TDD, da schreiben sie die Tests vorher. Irgendwo da zwischen “mal ausführen” und “TDD praktizieren” finden sich wohl die allermeisten Entwickler wieder. Wobei ich nicht behaupten möchte, dass TDD das non plus ultra wäre, aber es ist aus der Sicht der Testbarkeit und Testabdeckung ein sehr guter Weg.

Ansonsten stimme ich maki eigentlich vollkommen zu. Und wer sich mit Unit-Tests, automatisierten Tests und letzt TDD beschäftigt, der wird merken welche Vorteile es hat. Vielleicht nicht sofort, aber mit der Zeit lernt man es. Ich würde nicht behaupten, dass ich das besonders gut drin hätte, oft schreibe ich auch noch Code ohne vorher an Tests überhaupt zu denken. Aber mir ist bewusst, dass ich mit TDD letztendlich Code produziere, den ich nach einiger Zeit besser anschauen und wiederverwenden kann. Das ist nunmal so ein Erfahrungswert.

18

Also meines Wissens gibt es keine Entwickler die nicht testen. Es gibt nur Entwickler, die nicht testen müssen, weil dies eine TestUnit für ihn tut. Wenn Code, der zwar kompiliert aber nicht läuft, verbreitet wird, wurde er nicht von einem Entwickler gecoded sondern eher von einem Möchtegern. Nicht jeder, der Software entwickelt muss auch ein Entwickler sein. Mit anderen Worten: Entwickler sind für die Funktionalität ihrer Software letztendlich doch delber verantwortlich, selbst wenn in irgendwelchen Disclaimern steht, dass sie es nicht seien. Wer also ist schon so dämlich und verbreitet nicht funktionierenden Schrott, in dem Glauben, dass es eigentlich funktionieren müsste? Entwickler sicher nicht.
@bygones : Hacker-Joe sitzt hoffentlich nicht im Keller der NSA… weil dann würde es mich schon interessieren, was der so treibt. :wink:

19

haha - HackerJoe hockt ueberall :frowning:

20

Ja, polarisieren kann man mit diesem Thema vermutlich gut. Es gibt Bereiche, wo Unit-Tests in ihrer konsequentesten Form schlicht nicht praktikabel sind. Und dabei geht es nicht um „Hacker Joe“, sondern um Chefs, die zwar ein Budget für’s Bugfixing bereitstellen können (weil Bugs müssen ja gefixt werden), aber keins für’s Testen. Und wenn man da die Schuld dem Programmierer am Ende der Nahrungskette zuschiebt, macht man es sich zu einfach. Je weiter es nach oben geht, umso größer wird die Verantwortung für solche Dinge.

Und nun zu den Bereichen, wo Unit-Tests in ihrer konsequentesten Form nicht praktikabel sind: Fast alle. Tja, ihr TDD-Jünger, so sieht’s aus :stuck_out_tongue_winking_eye: Wer anderer Meinung ist, möge mir bitte zwei Unit-Tests schreiben: Einmal für java.util.Map und einmal für java.util.List. Ja, ich weiß, dass genau DAS die „umgekehrte Denkweise“ ist, und TDD gerade andersrum läuft, aber ich mache mal die polarisierende Aussage, dass das nur der erste Schritt von Ausflüchten ist, die hinführen zu ~„Najaaaa, für dies-und-das braucht man die ja nicht unbedingt, und die Programmierer wissen ja schon, was sie tun…“. Meine Aussage ist: Sowas ist nicht praktikabel. (Ich kenne nur einen „Gegenbeweis“ für diese Aussage, mal schaun, wer den findet :wink: )