it-swarm-eu.dev

Lohnt sich Unit Testing?

Ich arbeite daran, Unit-Tests in den Entwicklungsprozess des Teams zu integrieren, in dem ich arbeite, und es gibt einige Skeptiker. Was sind gute Möglichkeiten, die skeptischen Entwickler im Team vom Wert von Unit Testing zu überzeugen? In meinem speziellen Fall würden wir Unit-Tests hinzufügen, wenn wir Funktionen oder behobene Fehler hinzufügen. Leider eignet sich unsere Codebasis nicht zum einfachen Testen.

573
Ross Fuhrman

Jeden Tag findet in unserem Büro ein Austausch statt, der ungefähr so ​​aussieht:

"Mann, ich liebe Unit-Tests, ich konnte nur ein paar Änderungen an der Funktionsweise vornehmen und dann bestätigen, dass ich nichts kaputt gemacht habe, indem ich den Test erneut durchlief ..."

Die Details ändern sich täglich, die Stimmung jedoch nicht. Unit-Tests und testgetriebene Entwicklung (TDD) haben so viele versteckte und persönliche Vorteile, dass man sie nur dann jemandem erklären kann, wenn sie es selbst tun.

Aber, das ignorierend, hier ist mein Versuch!

  1. Mit Unit Tests können Sie schnell große Änderungen am Code vornehmen. Sie wissen, dass es jetzt funktioniert, da Sie die Tests ausgeführt haben. Wenn Sie die Änderungen vornehmen, die Sie vornehmen müssen, müssen Sie dafür sorgen, dass die Tests wieder funktionieren. Das spart Stunden.

  2. Mit TDD können Sie erkennen, wann Sie mit dem Codieren aufhören müssen. Ihre Tests geben Ihnen die Gewissheit, dass Sie für den Moment genug getan haben, und können aufhören, Änderungen vorzunehmen und mit dem nächsten Schritt fortfahren.

  3. Die Tests und der Code arbeiten zusammen, um einen besseren Code zu erzielen. Ihr Code könnte fehlerhaft sein. Dein TEST könnte schlecht/fehlerhaft sein. In TDD setzen Sie auf die Wahrscheinlichkeit, dass beide schlecht/fehlerhaft ist. Oft ist es der Test, der behoben werden muss, aber das ist immer noch ein gutes Ergebnis.

  4. TDD hilft bei der Codierung von Verstopfung. Wenn Sie mit einem großen und entmutigenden Stück Arbeit konfrontiert sind, bringen Sie die Tests schnell voran.

  5. Unit Tests helfen Ihnen dabei, das Design des Codes, an dem Sie arbeiten, wirklich zu verstehen. Anstatt Code zu schreiben, um etwas zu tun, skizzieren Sie zunächst alle Bedingungen, denen Sie den Code unterwerfen, und welche Ergebnisse Sie davon erwarten würden.

  6. Unit Tests geben Ihnen sofort visuelles Feedback. Wir alle mögen das Gefühl all dieser grünen Ampeln, wenn wir fertig sind. Es ist sehr befriedigend. Es ist auch viel einfacher, zu erkennen, wo Sie nach einer Unterbrechung aufgehört haben, weil Sie sehen können, wo Sie hingekommen sind - das nächste rote Licht, das repariert werden muss.

  7. Im Gegensatz zur gängigen Meinung bedeutet Unit Testing nicht, doppelt so viel Code zu schreiben oder langsamer zu codieren. Es ist schneller und robuster als das Codieren ohne Tests, sobald Sie den Dreh raus haben. Testcode selbst ist normalerweise relativ trivial und erhöht Ihren Aufwand nicht. Das wirst du nur glauben, wenn du es tust :)

  8. Ich denke, es war Fowler, der sagte: "Unvollständige Tests, die häufig durchgeführt werden, sind viel besser als perfekte Tests, die niemals geschrieben wurden." Ich interpretiere dies als Erlaubnis, Tests zu schreiben, bei denen ich denke, dass sie am nützlichsten sind, selbst wenn der Rest meiner Codeabdeckung absolut unvollständig ist.

  9. Gute Unit-Tests können dabei helfen, zu dokumentieren und zu definieren, was etwas tun soll

  10. Unit-Tests helfen bei der Wiederverwendung von Code. Migrieren Sie Ihren Code nd Ihre Tests zu Ihrem neuen Projekt. Ändern Sie den Code, bis die Tests erneut ausgeführt werden.

Eine Menge Arbeit, mit der ich zu tun habe, ist nicht gut für Unit Test (Interaktionen mit Webanwendungen usw.), aber trotzdem sind wir alle in diesem Shop mit Tests infiziert. Ich kann den Ansatz nicht genug empfehlen.

722
reefnet_alex

nit-Tests ähneln in etwa dem Gang ins Fitnessstudio. Sie wissen, dass es gut für Sie ist. Alle Argumente sind sinnvoll, also fangen Sie an zu trainieren. Es gibt einen anfänglichen Ansturm, der großartig ist, aber nach ein paar Tagen beginnt man sich zu fragen, ob es die Mühe wert ist. Sie nehmen sich eine Stunde Zeit, um sich umzuziehen und auf einem Hamsterrad zu rennen, und Sie sind sich nicht sicher, ob Sie wirklich etwas anderes als schmerzende Beine und Arme bekommen.

Dann, nach ein oder zwei Wochen, rückt eine große Frist näher. Sie müssen jede wache Stunde damit verbringen, "nützliche" Arbeit zu erledigen, damit Sie unnötige Dinge herausschneiden, wie zum Beispiel ins Fitnessstudio zu gehen. Du verlierst die Gewohnheit und wenn die große Frist abgelaufen ist, bist du wieder auf dem ersten Platz. Wenn du es schaffst, wieder ins Fitnessstudio zu kommen, fühlst du dich genauso wund wie beim ersten Mal.

Sie lesen etwas, um zu sehen, ob Sie etwas falsch machen. Man fühlt sich ein wenig irrational gegenüber all den gesunden, glücklichen Menschen, die die Tugenden des Trainings preisen. Sie erkennen, dass Sie nicht viel gemeinsam haben. Sie müssen nicht 15 Minuten aus dem Weg fahren, um ins Fitnessstudio zu gehen. Es gibt einen in ihrem Gebäude. Sie müssen sich mit niemandem über die Vorteile von Bewegung streiten. es ist einfach etwas, das jeder tut und als wichtig akzeptiert. Wenn sich eine große Frist nähert, wird ihnen nicht gesagt, dass Übung ebenso unnötig ist, wie Ihr Chef Sie auffordern würde, mit dem Essen aufzuhören.

m Ihre Frage zu beantworten, ist Unit Testing normalerweise die Mühe wert, aber der Aufwand ist nicht für alle gleich. Unit Testing kann einen enormen Aufwand erfordern, wenn Sie Es handelt sich um eine Spaghetti-Codebasis in einem Unternehmen, das keinen tatsächlichen Wert auf die Codequalität legt. (Viele Manager werden das Lob von Unit Testing singen, aber das bedeutet nicht, dass sie sich dafür einsetzen, wenn es darauf ankommt.)

Wenn Sie versuchen, Unit Testing in Ihre Arbeit einzuführen und nicht alle Sonnenstrahlen und Regenbögen sehen, die Sie erwartet haben, geben Sie sich nicht die Schuld. Möglicherweise müssen Sie einen neuen Job finden, damit Unit Testing wirklich für Sie funktioniert.

421
benzado

Der beste Weg, um zu überzeugen ... einen Fehler zu finden, einen Komponententest zu schreiben und den Fehler zu beheben.

Es ist unwahrscheinlich, dass dieser bestimmte Fehler jemals wieder auftritt, und Sie können ihn mit Ihrem Test beweisen.

Wenn Sie dies genug tun, werden andere schnell fangen.

136
Ed Guiness

die sprechende Walnuss fragt:

Was sind gute Möglichkeiten, die skeptischen Entwickler im Team vom Wert von Unit Testing zu überzeugen?

Jeder hier wird aus heiterem Himmel viele Gründe anhäufen, warum Unit-Tests gut sind. Ich finde jedoch, dass der beste Weg, jemanden von etwas zu überzeugen, oft darin besteht, auf sein Argument zu hören und es Punkt für Punkt anzusprechen. Wenn Sie ihnen zuhören und sie dabei unterstützen, ihre Bedenken auszudrücken, können Sie sich mit jedem einzelnen befassen und sie möglicherweise in Ihre Sichtweise umwandeln (oder sie zumindest ohne Bein stehen lassen). Wer weiß? Vielleicht überzeugen sie Sie, warum Unit-Tests für Ihre Situation nicht geeignet sind. Nicht wahrscheinlich, aber möglich. Vielleicht können wir Ihnen helfen, die Gegenargumente zu identifizieren, wenn Sie ihre Argumente gegen Unit-Tests posten.

Es ist wichtig, beide Seiten des Arguments anzuhören und zu verstehen. Wenn Sie versuchen, Komponententests zu eifrig durchzuführen, ohne Rücksicht auf die Sorgen der Menschen, werden Sie in einen Religionskrieg verwickelt (und wahrscheinlich wirklich wertlose Komponententests). Wenn Sie es langsam anwenden und mit der Anwendung beginnen, bei der Sie den größten Nutzen zu den geringsten Kosten erzielen, können Sie möglicherweise den Wert von Komponententests nachweisen und haben eine bessere Chance, die Menschen zu überzeugen. Mir ist klar, dass dies nicht so einfach ist, wie es sich anhört - es erfordert normalerweise einige Zeit und sorgfältige Metriken, um ein überzeugendes Argument zu finden.

Unit-Tests sind wie jedes andere Tool auch ein Werkzeug und sollten so angewendet werden, dass die Vorteile (das Auffinden von Fehlern) die Kosten (den Aufwand beim Schreiben) überwiegen. Verwenden Sie sie nicht, wenn/wo sie keinen Sinn ergeben, und denken Sie daran, dass sie nur ein Teil Ihres Arsenals an Werkzeugen sind (z. B. Inspektionen, Behauptungen, Codeanalysatoren, formale Methoden usw.). Was ich meinen Entwicklern sage, ist Folgendes:

  1. Sie können das Schreiben eines Tests für eine Methode überspringen, wenn sie ein gutes Argument dafür haben, warum es nicht notwendig ist (z. B. zu einfach, um es wert zu sein, oder zu schwierig, um es wert zu sein) und wie die Methode anderweitig verifiziert wird (z. B. Inspektion, Behauptungen) , formale Methoden, interaktive/Integrationstests). Sie müssen berücksichtigen, dass einige Überprüfungen wie Inspektionen und formale Nachweise zu einem bestimmten Zeitpunkt durchgeführt werden und dann jedes Mal wiederholt werden müssen, wenn sich der Produktionscode ändert, während Komponententests und Behauptungen als Regressionstests verwendet werden können (einmal geschrieben und danach wiederholt ausgeführt) ). Manchmal stimme ich ihnen zu, aber häufiger diskutiere ich darüber, ob eine Methode wirklich zu einfach oder zu schwierig für einen Komponententest ist.

    • Wenn ein Entwickler argumentiert, dass eine Methode zu einfach ist, um zu scheitern, lohnt es sich dann nicht, die 60 Sekunden in Anspruch zu nehmen, um einen einfachen 5-Zeilen-Komponententest dafür zu schreiben? Diese 5 Codezeilen werden für das nächste Jahr oder länger jede Nacht ausgeführt (Sie führen nächtliche Builds durch, oder?) Und sind die Mühe wert, wenn auch nur ein einziges Mal ein Problem aufgetreten ist, dessen Identifizierung 15 Minuten oder länger gedauert hat und debuggen. Außerdem erhöht das Schreiben der einfachen Komponententests die Anzahl der Komponententests, wodurch der Entwickler gut aussieht.

    • Wenn ein Entwickler dagegen argumentiert, dass eine Methode zu schwierig für einen Komponententest zu sein scheint (und nicht den erheblichen Aufwand wert ist), ist dies möglicherweise ein gutes Indiz dafür, dass die Methode aufgeteilt oder überarbeitet werden muss, um die einfachen Teile zu testen. In der Regel sind dies Methoden, die auf ungewöhnlichen Ressourcen wie Singletons, der aktuellen Uhrzeit oder externen Ressourcen wie einer Datenbank-Ergebnismenge basieren. Diese Methoden müssen normalerweise in eine Methode umgestaltet werden, die die Ressource abruft (z. B. getTime ()), und eine Methode, die die Ressource als Argument verwendet (z. B. den Zeitstempel als Parameter). Ich ließ sie das Testen der Methode, die die Ressource abruft, überspringen und stattdessen einen Komponententest für die Methode schreiben, die jetzt die Ressource als Argument verwendet. In der Regel vereinfacht dies das Schreiben des Komponententests erheblich und das Schreiben lohnt sich daher.

  2. Der Entwickler muss eine "Linie im Sand" ziehen, wie umfassend seine Komponententests sein sollten. Wenn wir später in der Entwicklung einen Fehler finden, sollten sie feststellen, ob umfassendere Komponententests das Problem behoben hätten. Wenn dies der Fall ist und solche Fehler wiederholt auftreten, müssen sie die "Linie" in Richtung eines Schreibens umfassenderer Komponententests in der Zukunft verschieben (beginnend mit dem Hinzufügen oder Erweitern des Komponententests für den aktuellen Fehler). Sie müssen das richtige Gleichgewicht finden.

Es ist wichtig zu erkennen, dass Unit-Tests keine Wunderwaffe sind, und es gibt so etwas wie zu viele Unit-Tests. Wenn wir an meinem Arbeitsplatz eine Lektion lernen, höre ich unweigerlich "wir müssen mehr Komponententests schreiben". Das Management nickt zustimmend, weil es ihnen in den Kopf geschlagen wurde, dass "Unit Tests" = "gut" sind.

Wir müssen jedoch die Auswirkungen von "mehr Komponententests" verstehen. Ein Entwickler kann nur ~ N Codezeilen pro Woche schreiben, und Sie müssen herausfinden, wie viel Prozent dieses Codes Unit-Test-Code im Vergleich zum Produktionscode sein sollen. Auf einem lockeren Arbeitsplatz können 10% des Codes als Komponententests und 90% des Codes als Produktionscode verwendet werden, was zu Produkten mit vielen (wenn auch sehr fehlerhaften) Funktionen führt (siehe MS Word). Auf der anderen Seite wird ein strenger Laden mit 90% Unit-Tests und 10% Produktionscode ein absolut solides Produkt mit sehr wenigen Merkmalen haben (denke "vi"). Sie werden vielleicht nie Berichte über das Abstürzen des letzteren Produkts hören, aber das hat wahrscheinlich so viel mit dem Produkt zu tun, das sich nicht so gut verkauft, wie es mit der Qualität des Codes zu tun hat.

Schlimmer noch, vielleicht ist die einzige Gewissheit in der Softwareentwicklung, dass "Veränderungen unvermeidlich sind". Angenommen, der strenge Shop (90% Unit-Tests/10% Produktionscode) erstellt ein Produkt mit genau 2 Merkmalen (unter der Annahme von 5% des Produktionscodes == 1 Merkmal). Wenn der Kunde mitkommt und eines der Features ändert, werden 50% des Codes (45% der Komponententests und 5% des Produktionscodes) in den Papierkorb verschoben. Der Lax Shop (10% Unit Tests/90% Production Code) hat ein Produkt mit 18 Features, von denen keines sehr gut funktioniert. Ihr Kunde überarbeitet die Anforderungen für 4 seiner Funktionen vollständig. Obwohl die Änderung viermal so groß ist, wird nur die Hälfte der Codebasis verworfen (~ 25% = ~ 4,4% Unit-Tests + 20% des Produktionscodes).

Mein Punkt ist, dass Sie kommunizieren müssen, dass Sie diese Balance zwischen zu wenig und zu viel Unit-Tests verstehen - im Wesentlichen, dass Sie beide Seiten des Problems durchdacht haben. Wenn Sie Ihre Kollegen und/oder Ihr Management davon überzeugen können, gewinnen Sie an Glaubwürdigkeit und haben möglicherweise eine bessere Chance, sie für sich zu gewinnen.

69
Bert F

Ich habe einige Male mit Unit-Tests gespielt und bin immer noch davon überzeugt, dass es sich in Anbetracht meiner Situation lohnt, sich anzustrengen.

Ich entwickle Websites, bei denen ein Großteil der Logik darin besteht, Daten in der Datenbank zu erstellen, abzurufen oder zu aktualisieren. Als ich versucht habe, die Datenbank für Unit-Test-Zwecke zu "verspotten", wurde sie sehr unübersichtlich und schien ein bisschen sinnlos.

Wenn ich Unit-Tests zur Geschäftslogik geschrieben habe, hat es mir auf lange Sicht nie wirklich geholfen. Da ich größtenteils nur an Projekten arbeite, weiß ich intuitiv, welche Codebereiche von etwas betroffen sein können, an dem ich arbeite, und teste diese Bereiche manuell. Ich möchte meinem Kunden so schnell wie möglich eine Lösung liefern, und Unit-Tests erscheinen oft als Zeitverschwendung. Ich liste manuelle Tests auf, gehe sie selbst durch und kreuze sie an, wenn ich gehe.

Ich kann sehen, dass es nützlich sein kann, wenn ein Entwicklerteam an einem Projekt arbeitet und sich gegenseitig den Code aktualisiert, aber selbst dann denke ich, dass gute Kommunikation und gut geschriebener Code oft ausreichen sollten, wenn die Entwickler von hoher Qualität sind .

38
Ronnie

Eine großartige Sache bei Unit-Tests ist, dass sie als Dokumentation für das Verhalten Ihres Codes dienen. Gute Tests sind so etwas wie eine Referenzimplementierung, und Teamkollegen können sie sich ansehen, um zu sehen, wie sie ihren Code in Ihren Code integrieren können.

31
pkaeding

Unit-Testing ist die Anfangsinvestition wert. Seitdem ich vor ein paar Jahren angefangen habe, Unit-Tests zu verwenden, habe ich einige echte Vorteile festgestellt:

  • Regressionstest beseitigt die Angst, Änderungen am Code vorzunehmen (nichts geht über das warme Leuchten, wenn man sieht, wie Code bei jeder Änderung funktioniert oder explodiert)
  • ausführbare Codebeispiele für andere Teammitglieder (und Sie selbst in sechs Monaten ..)
  • gnadenloses Refactoring - das ist unglaublich lohnend, probieren Sie es aus!

Code-Schnipsel können eine große Hilfe sein, um den Aufwand beim Erstellen von Tests zu verringern. Es ist nicht schwierig, Snippets zu erstellen, mit denen sich in Sekundenschnelle ein Klassenumriss und ein zugehöriges Unit-Test-Fixture erstellen lassen.

26
Jonathan Webb

Sie sollten so wenig wie möglich testen!

das heißt, Sie sollten gerade genug Komponententests schreiben, um die Absicht zu offenbaren. Dies wird oft beschönigt. Unit Testing kostet Sie. Wenn Sie Änderungen vornehmen und Tests ändern müssen, sind Sie weniger agil. Halten Sie Unit-Tests kurz und bündig. Dann haben sie viel Wert.

Zu oft sehe ich viele Tests, die niemals brechen werden, groß und ungeschickt sind und nicht viel Wert bieten. Sie verlangsamen dich einfach.

25
Keith Nicholas

Ich habe dies in keiner der anderen Antworten gesehen, aber eines ist mir aufgefallen: Ich könnte so viel schneller debuggen. Sie müssen Ihre App nicht in genau der richtigen Reihenfolge durchgehen, um zu dem Code zu gelangen, den Sie repariert haben. Sie müssen nur feststellen, dass Sie einen booleschen Fehler gemacht haben und alles erneut ausführen. Mit einem Komponententest können Sie direkt in den Code eintreten, den Sie debuggen.

23
John MacIntyre

[Ich habe einen Punkt zu machen, den ich oben nicht sehen kann]

"Jeder Unit-Test, der es nicht unbedingt merkt - FACT"

Denken Sie darüber nach, Sie schreiben eine Funktion, um möglicherweise eine Zeichenfolge zu analysieren und neue Zeilenzeichen zu entfernen. Als Neuling-Entwickler können Sie entweder einige Fälle von der Befehlszeile aus durchlaufen, indem Sie sie in Main () implementieren, oder Sie basteln ein visuelles Front-End mit einer Schaltfläche, binden Ihre Funktion an ein paar Textfelder und eine Schaltfläche und sehen was geschieht.

Das ist Unit-Test - einfach und schlecht zusammengesetzt, aber Sie testen den Code für ein paar Fälle.

Sie schreiben etwas komplexer. Es wirft Fehler auf, wenn Sie einige Fälle durchgehen (Unit-Tests) und Sie trotzdem in den Code debuggen und verfolgen. Sie betrachten Werte, während Sie sie durchlaufen, und entscheiden, ob sie richtig oder falsch sind. Dies ist bis zu einem gewissen Grad ein Unit-Test.

Bei Unit-Tests wird dieses Verhalten in ein strukturiertes Muster umgewandelt und gespeichert, damit Sie diese Tests problemlos wiederholen können. Wenn Sie einen "richtigen" Einheitentestfall schreiben, anstatt ihn manuell zu testen, dauert es genauso lange oder vielleicht auch weniger, als Sie erfahren haben, und Sie können ihn immer wieder wiederholen

21
Chris Gill

Ich habe jahrelang versucht, die Leute davon zu überzeugen, dass sie einen Komponententest für ihren Code schreiben mussten. Egal, ob sie die Tests zuerst geschrieben haben (wie in TDD) oder nachdem sie die Funktionalität codiert haben, ich habe immer versucht, ihnen alle Vorteile von Komponententests für Code zu erklären. Kaum jemand widersprach mir. Sie können mit etwas Offensichtlichem nicht einverstanden sein, und jede kluge Person wird die Vorteile von Unit-Test und TDD erkennen.

Das Problem bei Unit-Tests besteht darin, dass eine Verhaltensänderung erforderlich ist und es sehr schwierig ist, das Verhalten von Personen zu ändern. Mit Worten werden Sie viele Menschen dazu bringen, Ihnen zuzustimmen, aber Sie werden nicht viele Veränderungen in der Art und Weise sehen, wie sie Dinge tun.

Sie müssen die Leute überzeugen, indem Sie tun. Ihr persönlicher Erfolg wird mehr Menschen anziehen als alle Ihre Argumente. Wenn sie sehen, dass Sie nicht nur über Unit Test oder TDD sprechen, sondern das tun, was Sie predigen, und Erfolg haben, werden die Leute versuchen, Sie zu imitieren.

Sie sollten auch eine Hauptrolle übernehmen, da niemand gleich beim ersten Mal einen Unit-Test schreibt. Unter Umständen müssen Sie sie darin coachen, wie es geht, ihnen den Weg weisen und welche Tools ihnen zur Verfügung stehen. Helfen Sie ihnen, während sie ihre ersten Tests schreiben, überprüfen Sie die Tests, die sie selbst schreiben, und zeigen Sie ihnen die Tricks, Redewendungen und Muster, die Sie durch Ihre eigenen Erfahrungen gelernt haben. Nach einer Weile werden sie die Vorteile selbst erkennen und ihr Verhalten ändern, um Komponententests oder TDD in ihre Toolbox aufzunehmen.

Änderungen werden nicht über Nacht stattfinden, aber mit ein wenig Geduld können Sie Ihr Ziel erreichen.

16
Curro

Ein wesentlicher Teil der testgetriebenen Entwicklung, der oft übersehen wird, ist das Schreiben von testbarem Code. Zunächst scheint es eine Art Kompromiss zu sein, aber Sie werden feststellen, dass testbarer Code letztendlich auch modular, wartbar und lesbar ist. Wenn Sie immer noch Hilfe brauchen, um Menschen zu überzeugen this ist eine einfache Präsentation über die Vorteile von Unit-Tests.

12
Tom Martin

Wenn sich Ihre vorhandene Codebasis nicht für Komponententests eignet und bereits in der Produktion ist, können Sie möglicherweise mehr Probleme verursachen, als Sie lösen, indem Sie versuchen, Ihren gesamten Code so umzugestalten, dass er für Komponententests geeignet ist.

Sie sind möglicherweise besser dran, sich stattdessen um die Verbesserung Ihrer Integrationstests zu bemühen. Es gibt eine Menge Code, der ohne einen Komponententest einfacher zu schreiben ist. Wenn eine Qualitätssicherung die Funktionalität anhand eines Anforderungsdokuments validieren kann, sind Sie fertig. Es versenden.

Das klassische Beispiel hierfür ist meiner Meinung nach ein SqlDataReader, der in eine ASPX-Seite eingebettet ist, die mit einer GridView verknüpft ist. Der Code ist alles in der ASPX-Datei. Die SQL befindet sich in einer gespeicherten Prozedur. Was machen Sie Unit-Test? Wenn die Seite das tut, was sie tun soll, sollten Sie sie wirklich in mehrere Ebenen umgestalten, damit Sie etwas zu automatisieren haben?

11
Eric Z Beard

Eines der besten Dinge beim Testen von Einheiten ist, dass Ihr Code einfacher zu testen ist, wenn Sie dies tun. Vorbestehender Code, der ohne Tests erstellt wurde, ist immer eine Herausforderung, da sie nicht für Komponententests gedacht waren. Daher ist es nicht selten, dass die Kopplung zwischen Klassen und schwer zu konfigurierenden Objekten in Ihrer Klasse hoch ist - wie bei einer E-Mail Servicereferenz senden - und so weiter. Aber lass dich davon nicht stürzen! Sie werden feststellen, dass Ihr gesamtes Code-Design besser wird, wenn Sie anfangen, Komponententests zu schreiben. Je mehr Sie testen, desto sicherer werden Sie, noch mehr Änderungen daran vorzunehmen, ohne befürchten zu müssen, Ihre Anwendung zu beschädigen oder Fehler einzuführen .

Es gibt mehrere Gründe, Ihren Code in Einheiten zu testen. Im Laufe der Zeit werden Sie jedoch feststellen, dass die Zeit, die Sie beim Testen sparen, einer der besten Gründe dafür ist. In einem System, das ich gerade ausgeliefert habe, bestand ich darauf, automatisierte Komponententests durchzuführen, obwohl behauptet wurde, ich würde viel mehr Zeit für die Tests aufwenden als für das manuelle Testen des Systems. Nachdem alle Unit-Tests abgeschlossen waren, führte ich in weniger als 10 Minuten mehr als 400 Testfälle aus. Jedes Mal, wenn ich eine kleine Änderung am Code vornehmen musste, musste ich lediglich sicherstellen, dass der Code immer noch ohne Bugs funktionierte Protokoll. Können Sie sich vorstellen, wie viel Zeit Sie damit verbringen würden, diese über 400 Testfälle von Hand auszuführen?

Wenn es um automatisierte Tests geht - ob Unit-Tests oder Abnahmetests -, sind alle der Meinung, dass es eine Verschwendung ist, zu codieren, was Sie manuell tun können, und manchmal ist es wahr, wenn Sie vorhaben, Ihre Tests nur einmal auszuführen. Das Beste an automatisierten Tests ist, dass Sie sie ohne Aufwand mehrmals ausführen können und nach dem zweiten oder dritten Durchlauf die Zeit und den Aufwand, die Sie verschwendet haben ist bereits bezahlt.

Ein letzter Ratschlag wäre, nicht nur Ihren Code zu testen, sondern zuerst mit dem Testen zu beginnen (siehe TDD und BDD für weitere Informationen).

10

Unit-Tests sind auch besonders nützlich, wenn es darum geht, einen Code umzugestalten oder neu zu schreiben. Wenn Sie eine gute Abdeckung durch Komponententests haben, können Sie mit Zuversicht umgestalten. Ohne Unit-Tests ist es oft schwierig sicherzustellen, dass Sie nichts kaputt gemacht haben.

8
killdash10

Ich arbeite als Wartungstechniker einer schlecht dokumentierten, schrecklichen und großen Codebasis. Ich wünschte, die Leute, die den Code geschrieben haben, hätten die Unit-Tests dafür geschrieben.
Jedes Mal, wenn ich eine Änderung vornehme und den Produktionscode aktualisiere, habe ich Angst, dass ich einen Fehler einbringe, weil ich eine Bedingung nicht berücksichtigt habe.
Wenn sie den Test schreiben würden, wäre es einfacher und schneller, Änderungen an der Codebasis vorzunehmen (gleichzeitig wäre die Codebasis in einem besseren Zustand).

Ich denke, Unit-Tests erweisen sich als sehr nützlich, wenn Sie APIs oder Frameworks schreiben, die viele Jahre dauern müssen und von anderen als den ursprünglichen Programmierern verwendet/modifiziert/weiterentwickelt werden sollen.

7
mic.sca

Kurz gesagt - ja. Sie sind jede Unze Mühe wert ... bis zu einem gewissen Punkt. Letztendlich handelt es sich bei den Tests immer noch um Code, und ähnlich wie beim typischen Codewachstum müssen Ihre Tests möglicherweise überarbeitet werden, um wartbar und nachhaltig zu sein. Es gibt eine Tonne GOTCHAS! Wenn es um Unit-Tests geht, aber man oh man oh man, nichts, und ich meine, NICHTS befähigt einen Entwickler, Änderungen sicherer vorzunehmen als ein umfangreicher Satz von Unit-Tests.

Ich arbeite gerade an einem Projekt ... es ist eine Art TDD, und wir haben den größten Teil unserer Geschäftsregeln als Tests zusammengefasst ... wir haben ungefähr 500 Unit-Tests im Moment. In dieser letzten Iteration musste ich unsere Datenquelle überarbeiten und wie unsere Desktop-Anwendung mit dieser Datenquelle kommuniziert. Ich habe ein paar Tage gebraucht, die ganze Zeit habe ich nur Unit-Tests durchgeführt, um zu sehen, was ich kaputt gemacht und repariert habe. Nehmen Sie eine Änderung vor; Erstellen Sie Ihre Tests und führen Sie sie aus. Repariere, was du kaputt gemacht hast. Waschen, ausspülen, bei Bedarf wiederholen. Was traditionell Tage der Qualitätssicherung und der Belastung des Bootes gedauert hätte, war stattdessen eine kurze und erfreuliche Erfahrung.

Mit ein wenig mehr Aufwand im Voraus vorbereiten und es zahlt sich zehnmal später aus, wenn Sie anfangen müssen, mit den Kernfunktionen herumzuspielen.

Ich habe dieses Buch gekauft - es ist eine Bibel mit xUnit Testing-Kenntnissen - es ist wahrscheinlich eines der Bücher, auf die ich am häufigsten in meinem Regal verweise, und ich konsultiere es täglich: Linktext

7
cranley

Gelegentlich verbringen entweder ich selbst oder einer meiner Kollegen ein paar Stunden damit, den Grund für einen etwas undurchsichtigen Fehler zu finden, und wenn die Ursache des Fehlers in 90% der Fälle gefunden wurde, ist der Code nicht einheitlich getestet. Der Komponententest ist nicht vorhanden, da der Entwickler aus Zeitgründen Abstriche macht, diese und weitere Fehlerbehebungsmaßnahmen jedoch verliert.

Wenn Sie sich nur wenig Zeit nehmen, um einen Komponententest zu schreiben, können Sie Stunden beim zukünftigen Debuggen sparen.

7
Jon Cahill

Wenn Sie sagten, "unsere Codebasis eignet sich nicht zum einfachen Testen", ist dies das erste Anzeichen für einen Codegeruch. Schreiben von Komponententests bedeutet, dass Sie Code normalerweise anders schreiben, um den Code testbarer zu machen. Dies ist meiner Meinung nach eine gute Sache, da ich im Laufe der Jahre beim Schreiben von Code, für den ich Tests schreiben musste, gesehen habe, dass ich gezwungen war, ein besseres Design zu entwickeln.

6
Keith Elder

Ich weiß es nicht. Viele Orte führen keinen Komponententest durch, aber die Qualität des Codes ist gut. Microsoft macht Unit-Test, aber Bill Gates gab einen Bluescreen bei seiner Präsentation.

6
BigTiger

Unit Testing lohnt sich auf jeden Fall. Leider haben Sie ein schwieriges (aber leider häufig vorkommendes) Szenario ausgewählt, in das Sie es implementieren möchten.

Der beste Vorteil von Unit-Tests ist, dass Sie sie von Grund auf verwenden - bei einigen ausgewählten kleinen Projekten hatte ich das Glück, meine Unit-Tests zu schreiben, bevor ich meine Klassen implementierte (die Benutzeroberfläche war zu diesem Zeitpunkt bereits vollständig) Punkt). Mit den richtigen Unit-Tests finden und beheben Sie Fehler in Ihren Klassen, während sie noch in den Kinderschuhen stecken, und nicht in der Nähe des komplexen Systems, in das sie zweifellos in Zukunft integriert werden.

Wenn Ihre Software solide objektorientiert ist, sollten Sie in der Lage sein, Unit-Tests auf Klassenebene ohne großen Aufwand hinzuzufügen. Wenn Sie nicht so glücklich sind, sollten Sie trotzdem versuchen, Unit-Tests einzubeziehen, wo immer Sie können. Vergewissern Sie sich, wenn Sie neue Funktionen hinzufügen, dass die neuen Teile mit klaren Schnittstellen gut definiert sind und dass Unit-Tests Ihr Leben erheblich erleichtern.

6
Matt

Ich habe einen sehr großen Blog-Beitrag zu diesem Thema geschrieben. Ich habe festgestellt, dass Unit-Tests allein die Arbeit nicht wert sind und normalerweise gekürzt werden, wenn die Fristen kürzer werden.

Anstatt von Unit-Tests aus der Sicht des "Test-After" zu sprechen, sollten wir uns den wahren Wert ansehen, der gefunden wurde, als Sie vor der Implementierung eine Spezifikation/einen Test/eine Idee verfassen wollten.

Diese einfache Idee hat die Art und Weise, wie ich Software schreibe, verändert und ich würde nicht mehr auf die "alte" Art zurückgreifen.

Wie die erste Testentwicklung mein Leben veränderte

5
Toran Billups

Eine Sache, die noch niemand erwähnt hat, ist die Verpflichtung aller Entwickler, einen vorhandenen automatisierten Test tatsächlich auszuführen und zu aktualisieren. Automatisierte Tests, auf die Sie zurückgreifen und die Sie aufgrund neuer Entwicklungen als defekt empfinden, verlieren viel an Wert und machen automatisierte Tests wirklich schmerzhaft. Die meisten dieser Tests weisen nicht auf Fehler hin, da der Entwickler den Code manuell getestet hat. Daher ist die für die Aktualisierung aufgewendete Zeit nur Verschwendung.

Die Skeptiker davon zu überzeugen, die Arbeit, die die anderen an Unit-Tests leisten, nicht zu zerstören, ist viel wichtiger, um den Wert der Tests zu ermitteln, und könnte einfacher sein.

Das stundenlange Aktualisieren von Tests, die bei jedem Update aus dem Repository aufgrund neuer Funktionen unterbrochen wurden, ist weder produktiv noch unterhaltsam.

3
Samuel Åslund

Ich habe TDD vor ein paar Jahren entdeckt und seitdem alle meine Lieblingsprojekte damit geschrieben. Ich habe geschätzt, dass es ungefähr genauso lange dauert, ein Projekt zu entwickeln, wie es für das gemeinsame Entwickeln eines Cowboys erforderlich ist, aber ich habe so viel Vertrauen in das Endprodukt, dass ich das Gefühl habe, etwas erreicht zu haben.

Ich habe auch das Gefühl, dass es meinen Designstil verbessert (viel schnittstellenorientierter, falls ich Dinge verspotten muss) und, wie der grüne Pfosten oben schreibt, bei der "Codierung von Verstopfung" hilft: wenn Sie nicht wissen, was Als nächstes schreiben, oder Sie haben eine entmutigende Aufgabe vor sich, können Sie klein schreiben.

Schließlich finde ich, dass die bei weitem nützlichste Anwendung von TDD das Debuggen ist, schon weil Sie bereits ein Interrogator-Framework entwickelt haben, mit dem Sie das Projekt dazu bringen können, den Fehler auf wiederholbare Weise zu produzieren.

3
Kaz Dragon

Ja - Unit Testing ist definitiv die Mühe wert, aber Sie sollten wissen, dass es keine Wunderwaffe ist. Unit Testing ist Arbeit und Sie müssen daran arbeiten, den Test auf dem neuesten Stand zu halten und ihn bei Codeänderungen zu berücksichtigen. Der gebotene Wert ist jedoch den Aufwand wert, den Sie investieren müssen indem Sie Ihre Tests nach einem Änderungscode ausführen. Der Trick besteht darin, sich nicht zu sehr auf die Arbeitseinheit einzulassen, die Sie testen, oder auf die Anforderungen für Gerüstprüfungen und darauf, wann ein Unit-Test wirklich ein Funktionstest ist usw. Über diese Dinge wird stundenlang gestritten am Ende und die Realität ist, dass jedes Testen, das Sie als Ihr Schreibcode durchführen, besser ist als es nicht zu tun. Das andere Axiom handelt von Qualität und nicht von Quantität - ich habe Codebasen mit Tausenden von Tests gesehen, die im Wesentlichen bedeutungslos sind, da der Rest nichts Nützliches oder domänenspezifisches wie Geschäftsregeln usw. der jeweiligen Domain testet. Ich habe auch Codebasen mit 30% Codeabdeckung gesehen, aber die Tests waren relevant, sinnvoll und wirklich beeindruckend, da sie die Kernfunktionalität des Codes testeten, für den sie geschrieben wurden, und ausdrückten, wie der Code verwendet werden sollte.

Einer meiner Lieblingstricks bei der Erforschung neuer Frameworks oder Codebasen ist es, Komponententests zu schreiben, um herauszufinden, wie die Dinge funktionieren. Es ist eine großartige Möglichkeit, mehr über etwas Neues zu erfahren, anstatt ein trockenes Dokument zu lesen :)

3
Vinny Carpenter

Vor kurzem habe ich genau die gleiche Erfahrung an meinem Arbeitsplatz gemacht und festgestellt, dass die meisten von ihnen die theoretischen Vorteile kannten, aber über die Vorteile speziell für sie verkauft werden mussten. Hier sind die Punkte, die ich (erfolgreich) verwendet habe:

  • Sie sparen Zeit bei negativen Tests, bei denen Sie unerwartete Eingaben (Nullzeiger, Werte außerhalb des zulässigen Bereichs usw.) verarbeiten, da Sie all diese Vorgänge in einem einzigen Prozess ausführen können.
  • Sie geben beim Kompilieren sofort Rückmeldung über den Stand der Änderungen.
  • Sie sind nützlich, um interne Datendarstellungen zu testen, die während der normalen Laufzeit möglicherweise nicht verfügbar sind.

und der große ...

  • Möglicherweise müssen Sie keine Komponententests durchführen, aber wenn jemand anderes hereinkommt und den Code ändert, ohne es vollständig zu verstehen, kann er viele der dummen Fehler auffangen, die er möglicherweise macht.
3
dlanod

Nach meiner Erfahrung sind Unit-Tests und Integrationstests in komplexen Software-Umgebungen ein "MUSS".

Um die Entwickler in Ihrem Team davon zu überzeugen, Komponententests zu schreiben, empfiehlt es sich möglicherweise, die Komponententest-Regressionsanalyse in Ihre Entwicklungsumgebung zu integrieren (z. B. in Ihren täglichen Erstellungsprozess).

Wenn Entwickler wissen, dass ein fehlgeschlagener Komponententest nicht so viel Zeit für die Fehlersuche benötigt, um das Problem zu finden, sind sie eher dazu angehalten, diese zu schreiben.

Hier ist ein Tool, das solche Funktionen bietet:

Einheitentest-Regressionsanalysetool

2
Liorp

Wenn Sie NUnit verwenden, besteht eine einfache, aber effektive Demo darin, NUnits eigene Testsuite (n) vor sich auszuführen. Eine echte Testsuite zu sehen, die einer Codebasis ein Workout verleiht, sagt mehr als tausend Worte ...

2
Garth Gilmour

Das einzige, was Sie bei Unit-Tests beachten sollten, ist, dass es für den Entwickler ein Trost ist.

Im Gegensatz dazu sind Funktionstests für die Benutzer bestimmt: Wenn Sie einen Funktionstest hinzufügen, testen Sie etwas, das der Benutzer sehen wird. Wenn Sie einen Komponententest hinzufügen, erleichtern Sie sich lediglich das Leben als Entwickler. In dieser Hinsicht ist es ein bisschen Luxus.

Denken Sie an diese Zweiteilung, wenn Sie zwischen dem Schreiben einer Einheit oder einem Funktionstest wählen müssen.

2
Cedric Beust

Ich stimme der Ansicht zu, die der Mehrheit hier entgegengesetzt ist: Es ist in Ordnung, keine Komponententests zu schreiben Besonders prototypenintensive Programme (z. B. KI) lassen sich nur schwer mit Komponententests kombinieren.

2
DSblizzard

Unit-Tests helfen viel bei Projekten, die größer sind, als ein Entwickler im Kopf haben kann. Sie ermöglichen es Ihnen, die Komponententestsuite vor dem Einchecken auszuführen und festzustellen, ob Sie etwas kaputt gemacht haben. Dies reduziert ein Los in Fällen, in denen Sie sitzen und Ihre Daumen drehen müssen, während Sie darauf warten, dass jemand anderes einen Fehler behebt, den sie eingecheckt haben, oder wenn Sie mühsam ihr Wechselgeld zurücksetzen müssen, damit Sie etwas Arbeit bekommen getan. Es ist auch beim Refactoring von unschätzbarem Wert, sodass Sie sicher sein können, dass der refactored Code alle Tests besteht, die der ursprüngliche Code durchgeführt hat.

2
Max Rible Kaehn

Mit der Unit Test Suite können Sie Änderungen am Code vornehmen, während die restlichen Funktionen erhalten bleiben. Das ist ein großer Vorteil. Verwenden Sie Unit-Test-Software und Regressionstestsuite, wenn Sie mit der Codierung der neuen Funktion fertig sind?.

2
Shinwari

Der springende Punkt beim Testen von Einheiten ist, das Testen zu vereinfachen. Es ist automatisiert. "Test machen" und fertig. Wenn es schwierig ist, Code zu testen, ist dies der beste Grund, Unit-Tests durchzuführen.

1
Deathbob

Erst heute musste ich eine Klasse wechseln, für die zuvor ein Komponententest geschrieben wurde.
Der Test selbst war gut geschrieben und enthielt Testszenarien, über die ich nicht einmal nachgedacht hatte.
Zum Glück haben alle Tests bestanden, und meine Änderung wurde schnell überprüft und mit Zuversicht in die Testumgebung übernommen.

1
crowne

Wenn Sie Software manuell testen, stehen Ihnen normalerweise einige wenige Tests/Aktionen zur Verfügung. Schließlich werden Sie Ihre Eingabedaten oder Aktionen automatisch ändern, sodass Sie sich um bekannte Probleme herum bewegen können. Unit-Tests sollten vorhanden sein, um Sie daran zu erinnern, dass die Dinge nicht richtig funktionieren.

Ich empfehle, Tests vor dem Code zu schreiben und neue Tests/Daten hinzuzufügen, um die Funktionalität des Hauptcodes zu verbessern!

1
Ray Hayes

Als Physikstudent bin ich sehr motiviert, tatsächlich zu beweisen , dass mein Code so funktioniert, wie er soll. Sie können dies entweder logisch beweisen, was sich mit zunehmender Komplexität der Implementierung drastisch verschlechtert, oder Sie können einen (möglichst genauen) empirischen Funktionsnachweis durch gute Tests erbringen.

Wenn Sie keinen logischen Funktionsnachweis erbringen, müssen Sie testen. Die einzige Alternative ist zu sagen "Ich denke, der Code funktioniert ...."

1
Fredrik

@ George Stocker "Leider eignet sich unsere Codebasis nicht zum einfachen Testen." Jeder ist sich einig, dass das Testen von Einheiten Vorteile bringt, aber es scheint, dass für diese Codebasis die Kosten hoch sind. Wenn die Kosten höher sind als der Nutzen, warum sollten sie dann begeistert sein? Hören Sie auf Ihre Kollegen; Vielleicht ist für sie der wahrgenommene Schmerz von Unit-Tests größer als der wahrgenommene Wert von Unit-Tests.

Versuchen Sie insbesondere, so schnell wie möglich an Wert zu gewinnen, und achten Sie nicht auf den Wert "xUnit ist grün", sondern auf sauberen Code, den Benutzer und Maintainer schätzen. Vielleicht müssen Sie Unit-Tests für eine Iteration beauftragen und dann diskutieren, ob sich die Mühe lohnt oder nicht.

1

Machen Sie die ersten Dinge, die Sie testen, die nicht mit Unit-Tests zusammenhängen. Ich arbeite hauptsächlich in Perl, das sind also Perl-spezifische Beispiele, die Sie jedoch anpassen können.

  • Lädt und kompiliert jedes Modul richtig? In Perl müssen Sie für jede Foo.pm in der Codebasis eine Foo.t erstellen, die Folgendes bewirkt:

    use_ok( 'Foo' );
    
  • Ist der gesamte POD (Plain Ol 'Documentation) richtig formatiert? Verwenden Sie Test :: Pod, um die Gültigkeit der Formatierung aller PODs in allen Dateien zu überprüfen.

Sie denken vielleicht nicht, dass dies große Dinge sind, und sie sind es auch nicht, aber ich kann Ihnen garantieren, dass Sie ein paar Slops erwischen. Wenn diese Tests einmal pro Stunde durchgeführt werden und die vorzeitige Übergabe einer Person erkannt wird, werden die Leute sagen: "Hey, das ist ziemlich cool."

1
Andy Lester

Einer der Vorteile von Unit-Tests ist die Vorhersagbarkeit.

Vor dem Unit-Test hätte ich mit größter Genauigkeit vorhersagen können, wie lange es dauern würde, etwas zu codieren, aber nicht, wie viel Zeit ich für das Debuggen benötigen würde.

Da ich in diesen Tagen planen kann, welche Tests ich schreiben werde, weiß ich, wie lange die Codierung dauern wird, und am Ende der Codierung ist das System bereits debuggt! Dies bringt Vorhersehbarkeit in den Entwicklungsprozess, wodurch ein Großteil des Drucks beseitigt wird und trotzdem die ganze Freude erhalten bleibt !!.

1
Raz

Unit Testing ist eine der am häufigsten verwendeten Methoden für qualitativ hochwertigen Code. Sein Beitrag zu einem stabileren, unabhängigeren und dokumentierteren Code hat sich bewährt. Unit-Test-Code wird als integraler Bestandteil Ihres Repositorys betrachtet und gehandhabt und erfordert daher Entwicklung und Wartung. Entwickler sind jedoch häufig mit einer Situation konfrontiert, in der die Ressourcen, die in Komponententests investiert werden, nicht so fruchtbar sind, wie man es erwarten würde. In einer idealen Welt wird jede Methode, die wir codieren, eine Reihe von Tests haben, die den Code abdecken und dessen Richtigkeit überprüfen. Normalerweise überspringen wir jedoch aus zeitlichen Gründen einige Tests oder schreiben solche mit schlechter Qualität. Unter Berücksichtigung der Ressourcen, die für die Entwicklung und Wartung von Komponententests aufgewendet werden, muss man sich angesichts der verfügbaren Zeit die Frage stellen, welcher Code die meisten Tests verdient. Und von den vorhandenen Tests, welche Tests sind es tatsächlich wert, aufbewahrt und gewartet zu werden? Siehe hier

0
RoiG

Mit Unit-Tests können Sie Software mit weniger Fehlern freigeben und gleichzeitig die Gesamtentwicklungskosten senken. Klicken Sie auf den Link, um mehr über die Vorteile des Komponententests zu erfahren.

0
Steve_0

Wen versuchst du zu überzeugen? Ingenieure oder Manager? Wenn Sie versuchen, Ihre Ingenieur-Mitarbeiter zu überzeugen, ist es meiner Meinung nach die beste Wahl, ihren Wunsch zu erfüllen, ein qualitativ hochwertiges Stück Software zu erstellen. Es gibt zahlreiche Studien, die belegen, dass es Fehler gibt, und wenn sie gute Arbeit leisten möchten, sollte dies für sie ausreichen.

Wenn Sie versuchen, das Management zu überzeugen, müssen Sie höchstwahrscheinlich eine Kosten-Nutzen-Überlegung anstellen, dass die Kosten für die unentdeckten Mängel höher sind als die Kosten für das Schreiben der Tests. Berücksichtigen Sie auch unvorhersehbare Kosten, z. B. den Verlust des Vertrauens der Kunden usw.

0
Craig H

Dies ist sehr .Net-zentriert, aber hat jemand versucht Pex?

Ich war äußerst skeptisch, bis ich es versuchte - und wow, was für eine Leistung. Bevor ich dachte "Ich werde nicht von diesem Konzept überzeugt sein, bis ich verstehe, was es ist, zu tun um mir zu nützen". Es dauerte einen einzigen Lauf, bis ich meine Meinung änderte und sagte: "Ich weiß nicht care woher Sie wissen, dass das Risiko einer tödlichen Ausnahme besteht, aber dort ) + ist und jetzt weiß ich, dass ich damit umgehen muss "

Vielleicht ist der einzige Nachteil dieses Verhaltens, dass es everything anzeigt und Ihnen einen Rückstand von sechs Monaten liefert. Aber wenn Sie Codeschulden hatten, hatten Sie immer Codeschulden, Sie wussten es einfach nicht. Einem PM zu sagen, dass es zweihunderttausend mögliche Fehlerpunkte gibt, wenn Sie, bevor Sie ein paar Dutzend bemerkt haben, eine unangenehme Aussicht haben, was bedeutet, dass das Konzept unbedingt zuerst erklärt wird .

0
Tom W