Eure Meinung zu exzessiver Nutzung von Interfaces?

[Kokujou]

Hallo,

Ich muss das jetzt irgendwo fragen wo ein paar mehr Meinungen zusammenkommen. Ich arbeite gerade an einem Projekt und bin auf eine neue Unart gestoßen, die in meinem Team wohl inzwischen als eine Art Standard gilt.

Undzwar ist es jetzt wohl gang und gebe für so ziemlich jede Funktion ein Interface bestehend aus einer einzigen Funktion anzulegen. Um das mal zu verdeutlichen wir haben 7 Interfaces bestehend aus einer einzigen Funktion. und diese Interfaces werden auch nirgends sonst benutzt. Es gibt nur eine Implementierung und es ist nicht absehbar dass sich das nochmal ändert.

Der Grund? Tests. Offenbar können nur durch einen Haufen unnützer und brach liegender Interfaces die methoden getestet werden...

Was nochmal eine ganz andere Geschichte ist, denn ich sehe auch nicht ein warum ich eine Funktion teste indem ich den gesamten Inhalt wegmocke. Alle begründungen die man mir dazu gibt klingen ehrlich gesagt wie schlechte Aussagen.

Ich hatte gehofft hier ein paar Meinungen dazu zu hören. Vielleicht gibt es ja tatsächlich eine rechtfertigung die ganze Codelesbarkeit zu zerstören und sie mit Interfaces zuzupflastern und ich bin einfach zu ignorant das zu verstehen. wenn ich ein paar mehrere Meinungen höre kann ich mich vielleicht besser damit abfinden.

Oder natürlich ihr seid meiner Meinung und sagt dass das kompletter mist ist XD

Pro Forma: Ich rede von C#

 

[FranzvonAssisi]

Was schreibt ihr denn?

In Java brauchst du z.B. keine Interfaces für Unit-Tests...

 

[Kokujou]

C#. Ganz offensichtlich gibt es da eine Moq-Klasse die es erlaubt die Funktionen in Interfaces zu definieren (...)

also kann man statt die Funktion z:b. einen Download konkret aufzurufen einfach sagen er soll halt ne Testdatei zurückgeben auf der man weiterarbeitet. oder einfach nur den Aufruf der Funktion bestätigen.

Ergänzung (9. Juli 2019)

Ganz nebenbei haben wir allein für das eine Projekt über 55 verschiedene Tests, einer sinnloser als der andere... und das soll jetzt irgendwie sinn machen...
in meinem Team sind Leute die schon jahrelange erfahrung mit C# haben aber ich kann mir genauso wenig vorstellen dass die Tests irgendeinen Sinn verfolgen als dass jemand mit 7 Jahren Berufserfahrung so kollossal daneben liegt. Für mich als Anfänger ist das quasi ein Alptraum weil ich nicht mehr weiß was ich glauben soll.

Statt dass man bei uns die Tests so schreibt dass sie uns eine hilfe sind ist es mir im ganzen Code noch nie untergekommen dass ein durchgefallener Test das überarbeiten der betroffenen Funktion nach sich zieht. Stattdessen verbessern wir immer nur den Test.

Ist das normal im heutigen Software-Entwicklungsprozess?

 

[Ungeziefer]

Ich kenne C# nicht aber in einem Unit-Test solltest du eine Klasse ohne ihre Abhängigkeiten testen. Daher werden Aufrufe an andere Klassen, Schnittstellen oder Systeme durch Mocks ersetzt. Dadurch lässt sich die Funktionalität genau dieser einen Klasse verifizieren ohne Abhängigkeiten. Daher ist es schon richtig, dass in einem Unit-Test sehr viel mit Mocks gearbeitet wird.
In einem Integrationstest (dieser kann auch in einem automatisierten Test geschrieben sein) sollten mehrere Klassen zusammen getestet werden. In deinem Beispiel wäre der Download einer Dummy-Datei und deren Verarbeitung schon ein Integrationstest.

Das Problem mit den Interfaces habe ich leider nicht verstanden. Kannst du dazu bitte ein Minimalbeispiel erstellen?

 

[Zonk91]

Das ganze wird dann interessant wenn du eine Komponente A in eine andere Komponente B hineingeben willst über Dependency Injection und nur die (isolierte) Logik von einer Methode von Komponente B über Unit-Tests testen willst, diese aber eine Methode von Komponente A verwendet und beispielsweise eine externe Abhängigkeit hat (DB, Webservice oder ähnliches). Die Abhängigkeit kannst du dann im Unittest mit einem Framework wegmocken. Bei euch über Moq. Ohne Interfaces wird das sonst schwierig.

 

[schasi]

Sehr interessante Frage. Leider kann ich nicht gut genug C#, um hier eine gute Antwort zu finden. Wenn das so schlimm ist wie es klingt, kannst du nicht der erste sein dem das auffällt. Ich hab aber bei einer kurzen Suche wenig dazu gefunden und hoffe, dass ein C#-Profi hier noch mehr dazu sagen kann.

Btw finde ich den Ausgangspost sehr suggestiv in Richtung "Klar ist das schlecht". So wie das gestellt ist klingt das natürlich nicht gut, daher wäre eine neutralere Ausdrucksweise hilfreich. Und natürlich mehr Infos, die aber nachgereicht wurden.

Bist du schon in den Dialog mit deinen Mitentwicklern gegangen? Ich würde an deiner Stelle nicht ganz ausschließen, dass mir noch die Informationen fehlen um das ganze Bild zu verstehen. Eventuell ist es, so wie es gemacht wird, einfach die am wenigsten schlechte Lösung von vielen

 

[Zonk91]

Der Grund? Tests. Offenbar können nur durch einen Haufen unnützer und brach liegender Interfaces die methoden getestet werden...

Das macht mich ein wenig stutzig. Die Interfaces sollten meiner Meinung nach nicht nur zum Zweck der Testbarkeit verwendet werden, sondern auch im produktiven Code verwendet werden um harte Kopplungen zu vermeiden, wo wir beim Thema Wartbarkeit wären.

 

[Kokujou]

Ich darf leider keinen Code veröffentlichen aber ich versuche es mal so zu sagen:

Man stelle sich vor man habe Eine Klasse deren Aufgabe die Koordination von Tasks ist die in Reihe ausgeführt werden. Verschiedene Aufgaben die also aufgeführt werden. Das sind natürlich komplexe Aufgaben wie Download, Installation oder sonst irgendwas was eben nicht mal schnell in nem Unit-Test-Scope getestet werden kann.

Implementiert ist es so dass der Koordinator einfach alle X sekunden sagt

Aufgabe1();
Aufgabe2();
Aufgabe3();

So. Jede dieser zugegeben komplexen Aufgaben hat jetzt ein Interface. Ein Interface dass etwas so aussieht:

interface Aufgabe1
{
void DoAufgabe1();
}

und so etwas liegt jetzt fast 10mal in unserem Projektordner. Jetzt testen wir doch tatsächlich die Koordinationsfunktion indem wir jede einzelne dieser Aufgaben wegmocken.

Also im Prinzip ist die einzige Aussage dieses testes "Ja, diese Funktionen werden doch tatsächlich aufgerufen".

wir verschwenden soviel Zeit damit guten Code zu "zerstrukturieren", dass die Grundfunktionalität von mir selbst übrigens schon seit einer Woche fertig ist und von allen sogar als "Guter Code" akzeptiert wurde und wir jetzt seit einer woche dabei sind unnütze interfaces einzubinden und dutzende von Tests zu machen weil "vielleicht mal irgendeine Komplexität dahinter sein könnte". Zitat.

Ich möchte hier klar stellen dass ich absolut nichts gegen Tests habe. Aber für mich sollten Tests kein unnützes Hindernis sein dass man sobald man auch nur ein Komma im Originalcode ändert sofort wieder anpassen muss.

Tests sollten etwas sein dass die Anforderungen an eine Funktion prüft. Also wenn man eine Funktion hat die z.B. aus einem String eine Url generiert sollte der Test sagen, dass wenn du einen string eingibst eine valide URL raus kommt. Machen wir das so? nein.

Wir sagen "Wenn du eingibst 'http://a.b.c' kommt 'http://a.b.c' als URL" raus und das prüfen wir dann für jede einzelne von uns verwendete Url.

Ich weiß meine Beschreibungen sind sehr voreingenommen aber es klingt für mich alles so sinnlos als würde man mir erklären warum 1+1 plötzlich 3 ist.

 

[umask007]

Also Interfaces mit einer Funktion kann man auch durch ein Delegate ersetzen (z.B. Func<> und Action).
Das kann helfen, den Wildwuchs an Interfaces einzudämmen und trotzdem lose Koppelung und Testbarkeit sicherzustellen.

 

[Zonk91]

und so etwas liegt jetzt fast 10mal in unserem Projektordner. Jetzt testen wir doch tatsächlich die Koordinationsfunktion indem wir jede einzelne dieser Aufgaben wegmocken.

Also im Prinzip ist die einzige Aussage dieses testes "Ja, diese Funktionen werden doch tatsächlich aufgerufen".

Macht aus meiner Sicht absolut Sinn. So stellst du sicher, dass ein Entwickler, der zu euch ins Team dazustößt nicht wie wild refactored und bespielsweise Aufgabe2() vergisst. Wenn doch sollte der Unit-Test auf rot laufen und spätestens in der CI/CD Pipeline dazuführen, dass sich das nochmal jemand ansieht.

Ich bin jedenfalls ein großer Fan von TDD (Test Driven Development). D.h. ich schreibe erst meine Unit-Tests auf Basis der Anforderungen und entwickle solange bis alle Unit-Tests grün sind.

Die Tests sind für viele leider Gottes ein sehr leidiges Thema. Das ganze zahlt sich eben nicht sofort aus und bedeutet erst mal Arbeit. Die können dir aber in Zukunft den Arsch retten, wenn du die Software, die du geschrieben hast auch noch länger maintainen musst. Du willst ja nicht, das du bei einem neuen Feature evtl. alte Akzeptanzkritieren/Verhaltensweisen unerwarteterweise brichst. Und glaub mir bei großen Code-bases passiert das schneller also du schauen kannst.

 

[Fellor]

Programmieren gegen Schnittstellen ist ein fudamentales Prinzip des OOA&D (Objektorientierte Analyse und Design) und prinzipiell begrüßenswert. In der Praxis erweißt es sich dennoch oft als sinnvoller nicht voll nach Lehrbuch zu gehen, sondern ein anwendbares Mittel zu finden. Gerade Unit Tests können einen enorm hohen Aufwand erzeugen.

Frag' doch einfach mal einen alten Hasen ob er dir den Hintergrund erklären kann.

 

[Axxid]

Die Testfälle sollen eben bestmöglich dokumentiert werden.
Wir (reine Softwaretester) haben von jedem Schritt Screenshots des Interfaces gemacht (oder machen lassen). Und selbst das hat nicht immer gereicht um Fehler nachzuvollziehen. Wenn ich an ein paar Fehler denke, kann man die Daten und Funktionen nicht genug dokumentieren.

Aber ich bin auch kein Entwickler.

 

[Yuuri]

Was nochmal eine ganz andere Geschichte ist, denn ich sehe auch nicht ein warum ich eine Funktion teste indem ich den gesamten Inhalt wegmocke. Alle begründungen die man mir dazu gibt klingen ehrlich gesagt wie schlechte Aussagen.

• damit Tests funktionieren
• dein Code erweiterbar bleibt (Wartbarkeit steigt enorm)
• damit externe Libs ordentlich integriert werden können (andere bei dir, sowie deine bei anderen - gehört auch ein wenig zur Wartbarkeit)

Ich hatte gehofft hier ein paar Meinungen dazu zu hören.

Interfaces sind super. Es gibt nichts Schlimmeres als wenn fixe (final?) Klassen in einer externen Lib genutzt werden und du gar keine Chance hast irgendwas zu überschreiben oder anzupassen. Da bleibt dir nichts üblich als das Teil selbst zu schreiben, zu forken oder um das Teil selbst nochmal zu kapseln.

Aber auch Tests werden dadurch erst ermöglicht, denn jede Abhängigkeit zu mocken ist gar nicht möglich (da bspw. Dependencies hardcoded verwendet werden). Ergo auch: exzessives DI und nix hardcoden.

Kannst dir ja mal league/oauth2-server ansehen, da siehst du warum Interfaces sinnvoll sind. Sie geben vor was gemacht werden soll, geben aber nicht vor wie. Genau die Definition von Interfaces. Sie geben gemeinsame Schnittstellen vor, damit hier eine externe Bibliothek Sachen erledigen kann, trotz dass sie nicht an deine Codebasis angepasst sein muss, sondern vollständig unabhängig arbeitet. Das Beispiel war eines der Schönen, die ich in letzter Zeit implementiert habe.

Du implementierst im Prinzip Interfaces und baust so Brücken zwischen deiner Codebase und der Lib. Und es funktioniert ohne dass an beiden Seiten irgendwas angepasst werden muss.

Mocken ist auch nicht immer möglich.

Beispiel:

<?php

$calc = new PriceCalculator();
$price = $calc->calculate( $product = 123, $amount = 5 );

class PriceCalculator
{
  public function calculate( $productId, $amount )
  {
    $product = new Product( $productId );
    return $product->getPrice() * $amount;
  }
}
class Product
{
  public static function fromDb( $id )
  {
    return MySQL::resolveProduct( $id );
  }
}

Die Abhängigkeit zur DB kannst du hiermit nicht lösen, da PriceCalculator::calculate() ne fixe Abhängigkeit hat. Tests sind also unmöglich, ohne das die DB einen Hit erfährt (was nicht sein sollte). Mocken geht nicht, wegen der fixen Dependency.

Erweiterung ist auch unmöglich. Was wenn du später mal die Produktpalette erweitern musst? Ich denke da bspw. an Versandprodukte, welche den Preis des Versandes beinhalten, aber nicht als eigenes Produkt geführt werden dürfen (über Suche oder Kategoriebaum auffindbar etc.). Oder wie wäre es mit individuell gestalteten Produkten, die auf den eigentlichen Produkten basieren, aber eine eigene Konfiguration mitbringen (und u.a. den Preis beeinflussen, aber auch bei der Bestellung anders dargestellt werden müssen)?

So erstellst du ein vom eigentlichen Produktstamm unabhängiges Produkt, wo du aber trotzdem bereits vorhandene Schnittstellen nutzen kannst.

Einfacher Fix: Einfach ein Interface vom Typ Product übergeben, so bist du gänzlich unabhängig von irgend einer Implementierung.

<?php

interface Product
{
  public function getPrice();
}

/** Produkt aus dem üblichen Sortiment - DB-Tabelle products */
class DbProduct implements Product {}

/** gesonderte Produkte vom Versand - DB-Tabelle shipping_products */
class ShippingProduct implements Product {}

/** holt das Produkt aus der Session, weil du das Produkt ggf. noch nicht
  fertig gespeichert hast und dieses noch nicht in der DB landete */
class TemporaryProduct implements Product {}

/** dein oben fertig angepasstes Produkt, nun aus der DB - Tabelle individual_products */
class IndividualProduct implements Product {}

$calc = new PriceCalculator();
$product = new DbProduct( 123 );
$shipping = new ShippingProduct( 456 );
$tmp = new TemporaryProduct( 789 );
$individual = new IndividualProduct( 101112 ); /** aus $tmp generiert */

$calc->calculate( $product, $amount = 5 );
$calc->calculate( $shipping, $amount = 5 );
$calc->calculate( $tmp, $amount = 100 );
$calc->calculate( $individual, $amount = 100 );

• beim Testen kann Product bzw. getPrice() einfach gemockt werden (trifft keine DB, keine Datei, nur den RAM), der PriceCalculator holt sich seine notwendige Dependency also über einen Parameter von dir, statt selbst aktiv zu werden
• Der letzte Punkt der Einbindung externer Libs sollte sich automatisch erklären (am Beispiel von league/oauth2-server).

 

[Ungeziefer]

....
Ist das normal im heutigen Software-Entwicklungsprozess?

In einer idealen Welt für den Softwareentwickler ist vor dem Implementieren schon klar, wie die Tests aussehen sollten. Ein Steakholder, Fachbereich oder Spezifikateur kann sagen, wie sich ein Stück Software zu verhalten hat und ein Entwickler kümmert sich erst um die Implementierung der Tests und dann der Software (Test-First-Entwicklung).
In der Realität sieht das immer etwas anders aus. Anforderungen ändern sich oder Tests werden vergessen (oder aus Zeitgründen weggelassen). Daher ist das, was du glauben sollst, immer im Code. Der sagt ganz genau, wie ein Programm sich verhält. Viele Entwickler wollen jedoch lieber Code schreiben als lesen und dann ist jeder Code schlecht, den man nicht selbst geschrieben hat.

...

und so etwas liegt jetzt fast 10mal in unserem Projektordner. Jetzt testen wir doch tatsächlich die Koordinationsfunktion indem wir jede einzelne dieser Aufgaben wegmocken.

Also im Prinzip ist die einzige Aussage dieses testes "Ja, diese Funktionen werden doch tatsächlich aufgerufen".
...

Das ist für mich auch Teil der Unit-Tests. Darin muss verifiziert werden, dass Mocks auch tatsächlich aufgerufen werden.
Wie gesagt, ich kenne C# überhaupt nicht aber ein Aufgabenmanagement hat viele abstrakte Aufgaben und hier ist eine lose Kopplung absolut nötig.

...
Tests sollten etwas sein dass die Anforderungen an eine Funktion prüft. Also wenn man eine Funktion hat die z.B. aus einem String eine Url generiert sollte der Test sagen, dass wenn du einen string eingibst eine valide URL raus kommt. Machen wir das so? nein.

Wir sagen "Wenn du eingibst 'http://a.b.c' kommt 'http://a.b.c' als URL" raus und das prüfen wir dann für jede einzelne von uns verwendete Url.
...

Das muss beides in Tests. Es werden (sehr wahrscheinlich) unterschiedliche Testklassen sein.

...
Ich weiß meine Beschreibungen sind sehr voreingenommen aber es klingt für mich alles so sinnlos als würde man mir erklären warum 1+1 plötzlich 3 ist.

Bitte gehe unvoreingenommen zu einem der erfahrenen Entwickler und lasse dir erklären, was die Ideen im Code und Testkonzept sind. Jedes Team hat sich dabei Gedanken gemacht und man kann davon etwas lernen.

 

[Kokujou]

Macht aus meiner Sicht absolut Sinn. So stellst du sicher, dass ein Entwickler, der zu euch ins Team dazustößt nicht wie wild refactored und bespielsweise Aufgabe2() vergisst. Wenn doch sollte der Unit-Test auf rot laufen und spätestens in der CI/CD Pipeline dazuführen, dass sich das nochmal jemand ansieht.

Naja dafür gibt's doch Pull Requests... aber das ist genau wie cih sage man müsste sich schon richtig mühe geben dass solche Tests fehl schlagen.

Ich bin jedenfalls ein großer Fan TDD (Test Driven Development). D.h. ich schreibe erst meine Unit-Tests auf Basis der Anforderungen und entwickle solange bis alle Unit-Tests grün sind.

Ja! Genau sowas verstehe ich auch. Aber wir machen das eben nicht. und sollen es auch gar nicht. wir interessieren uns nicht für die Anforderungen an eine Funktion. Wir testen die Fälle so speziell dass schon die kleinste (gewollte!) Änderung den Test zum Fehlschlagen zwingt obwohl er innerhalb der Spezifikationen ist. Also wenn wir z.B. sagen "okay, wir ändern den Port für unsere lokale API". Wir hätten nur wegen dieser kleinen Portnummer tagelang zutun die 20 darauf aufbauenden Tests zu fixen, obwohl alles korrekt funktioniert.

Wir verbringen so viel Zeit damit unseren Code zu verschlimmbessern ich kann ganz unbescheiden sagen dass ich schon vor einer Woche am liebsten zum PO gegangen wäre und ihm den fertigen und funktionierenden E2E-Test hingelegt hätte und gesagt hätte. "Ich bin schon fertig aber die andern wollen noch ein paar Wochen lang testen dass wenn ich eine Funktion aufrufe, ich eine Funktion aufrufe."

Ich möchte nochmal betonen:
Ich habe nichts gegen sinnvolle Tests. Wenn ich eine Funktion schreibe überlege ich mir immer genau was soll sie können wann soll sie Fehlschlagen. Ich will testen dass das was ich will auch passiert. Aber unsere Tests sind viel zu speziell. Sie schlagen entweder immer fehl oder sind immer grün.

Beispiel: Sagen wir wir haben eine Funktion die nichts weiter als ein Wrapper für nen HttpClient ist. der z.B. Konstanten reinschreibt damit wir weniger Parameter haben. Das ist die Spezifikation der Funktion. Weder muss getestet werden dass der HttpClient funktioniert noch muss funktioniert werden dass die Parameter die drinne stehen auch im HttpClient ankommen. Und doch schreiben wir 3 Tests dafür. Warum?


Ganz ehrlich bevor ich dort angefangen habe hab ich gar keine Unit tests gemacht. Gut es gab mal leidige Fehler die mich einen Tag gekostet haben aber besser einen Tag Fehlersuche als eine Woche Tests schreiben. Und mein damaliges Projekt war sogar größer und viel unübersichlticher als das was wir jetzt schreiben

So erstmal zwischenpost damit ich die anderen Beantworten kann ^^

Ergänzung (9. Juli 2019)

• damit Tests funktionieren
• dein Code erweiterbar bleibt (Wartbarkeit steigt enorm)
• damit externe Libs ordentlich integriert werden können (andere bei dir, sowie deine bei anderen - gehört auch ein wenig zur Wartbarkeit)

1. Wenn ein Test nur testet ob eine Funktion aufgerufen wird wenn du sie explizit aufrufst dann ist der Test sinnlos. Für mich zumindest.
2. Was hat Mocken denn mit Erweiterbarkeit zutun? Oder reden wir jetzt von Interfaces. Wenn wir die wenigstens verwenden würden. Ich meine ich hätte absolut kein Problem wenn ich z.B. sowas hätte:

interface IDownloadable
{
void GetMetaData();
void PingHost();
void DownloadFiles();
void VerifyDownload();
}

und es dann 3 verschiedene Implementierungen gibt die auf 3 verschiedene Arten downloaden. Das wäre für mich ein sinnvolles und gut platziertes Interface. Wir haben da drin eine Methode, wir hätten das Interface auch gleich 'Executable' nennen können und ne Funktion 'dosomething' reinschreiben können. Dann könnten wir es jetzt in jeder Methode implementieren.

Oder man macht eine abstrakte Klasse draus die die Funktionen die verwendet werden gleich noch sinnvoll orchestriert, also koordiniert. Sowas hab ich in meinem Master-Projekt sehr gerne verwendet da es sehr gut ist um eine Struktur zu erschaffen. Meine Leute sind selbstverständlich komplett dagegen sowas überhaupt zu benutzen... wäre ja auch ein wunder wenn ich mal was richtig mache.

 

[Zonk91]

Ein Steakholder

 

[Ungeziefer]

Ein freud'scher Vertipper. 😅

 

[Kokujou]

Man hat jetzt oft versucht es mir zu erklären aber es klingt je öfter ich es höre wie eine schlechte ausrede. Ich verstehe ja warum man gewisse tests macht aber... Bin ich wirklich der einzige der der Mienung ist dass es hier grüdlich übertrieben wird? Man kann gar nicht so schlecht schreiben dass so simple tests Fehlschlagen.

E2E-Test - Superwichtig. Quasi das End-Abnahmekriterium
Integrations-Tests: Wichtig. Sie Testen ja quasi die einzelne Komponente in ihrer Funktionalität.
Auch Unit-Tests können wichtig sein. Aber wenn jeder Entwickler schon anfängt an den grundlegensten Dingen zu zweifeln dann können wir die Entwicklung direkt sein lassen und Philosophen werden.

"Warum ist 1+1 eigentlich 2? Wer hat das bestimmt? Das muss erstmal getestet werden." ich will nicht wissen wie wenns nach denen geht ne Mnultiplikation getestet wird... natürlich für jedes mögliche Tupel einzeln. Denn es könnte ja sein dass wen 2*2 4 ist 4*4 dann doch irgendwie 21 ist! das muss natürlich einwandfrei ausgeschlossen werden.


Ich persönlich bin ja neu. Und ich meine wir müssen irgendwann zu unserem Boss gehen und ihm sagen was wir gemacht haben. Und ich kriege ein tierisch schlechtes gewissen wenn ich sagen muss: "Hey, wir haben aktuell nichts gemacht wir mussten erstmal feststellen dass wenn ich eine Funktion mit nem Parameter aufrufe, der Parameter auch ordentlich übergeben wird."
Denn man kann ausreden bringen so viel man will aber man stellt doch Profis an. Leute bei denen man nicht davon ausgehen muss dass sie so unglaublichen schwachsinn verzapfen dass man so penible tests braucht. Und wenn irgendein Genie daherkommt und meint alles refactoren zu müssen und plötzlich der ganze Build kaputt geht dannr ollt man die changes halt zurück oder integriert sie gar nicht erst.

Ich schreibe jetzt nen Monat mit an deren Code und bis jetzt ist es mir 100mal öfter passiert dass die Tests obsolet waren und überarbeitet werden müssen aber es ist noch NIE vorgekommen dass der Code mal wegen roter tests überarbeitet werden müsste. Erklärt mich für verrückt aber ich glaube das ist nicht optimal. Wenn ein Test rot wird sollte das eigentlich heißen "Achtung, dein Programm funktioniert nicht wie geplant." und nicht "Achtung, du hast ein komma hinzugefügt, der Test muss komplett überarbeitet werden damit er wieder erkennt dass alles richtig ist."

 

[schasi]

Sehr interessant, auch weil ich bald anfange als Entwickler zu arbeiten und schon gespannt bin wie es da im Detail sein wird. Freut mich, dass du anscheinend mit viel Begeisterung dabei bist.

So wie du es darstellst gibt es zwei Möglichkeiten:

1. Du hast mit deiner Einstellung recht.
2. Die anderen haben mit ihrer Einstellung recht.

Um das herauszufinden musst du wohl viel fragen und nachfragen. Und immer wieder offen sein, dass sowohl 1. als auch 2. gelten könnte. Bei 1. wäre wohl ein Jobwechsel angebracht (weil ich davon ausgehe, dass man da nicht viel ändern kann wenn "alle das so machen und es niemanden stört"), bei 2. ein Einstellungswechsel
Und noch zu 2.: Meistens haben solche Dinge eine Geschichte, einen Grund warum es so gekommen ist. Wenn man den herausfindet, dann kann man mehr Verständnis haben bzw. da ansetzen, ohne die Fehler die auf dem Weg gemacht wurden zu wiederholen.

Es geht natürlich letztendlich nicht ums "Recht haben", das ist auch noch wichtig. Aber so wie du die Situation darstellst (ohne den erweiterten Kontext zu kennen) ist das schlimm, ja. Da wäre ich auch frustriert.

 

[Kokujou]

Mein fehler ist es wohl dass ich zu viel Eifer an den Tag lege und gute Arbeit abliefern will. Heutzutage geht es aber wohl eher zu "joa erstmaln käffchen und dann n paar wochen lang tests schreiben. Ergebnisse? Pff... muss halt schön getestet sein."

Als Programmierer hat es mir immer "Spaß" gemacht neue Algorithmen zu entwickeln und Probleme zu lösen. Aber diese neue Clean Code, Testfanatikerbewegung hat mir dann gründlich den Spaß verdorben. Im Prinzip brauche ich von der einstellung her jetzt sowas wie es ist mir scheiß egal was am Ende rauskommt und wie viel Zeit ich mit unnützen nebentätigkeiten verschwende. Es ist völlig egal ob das Produkt funktioniert, wenn sinnlose tests rot sind die keinerlei aussage haben und den Entwickler mehr behindern als sie ihm je helfen könnten.

Jetzt weiß ich auch warum die Entwicklung meiner Lieblings-Programme immer so lange dauert und nie voran kommt. Weil die Leute zu sehr damit beschäftigt sind sinnlose dinge zu bearbeiten von denen der Kunde niemals etwas mitbekommen wird. Und die Windows Updates die ständig installiert werden sind zu 99% vermutlich auch nur irgendwelche Tests zu einem Feature dass der Nutzer auch niemals zu sehen kriegt.

Schöne neue Welt. Das ist zumindest der eindruck den ich kriege. so kann man als programmierer natürlich nicht besser werden weil es keine Qualitätsmaßstäbe mehr gibt. Wie auch. Jedes Komma muss ohnehin getestet sein. Aus Denkarbeit ist also bloßes abtippen geworden.

Ich bin sicher das klingt jetzt wieder sehr kontrovers und rückt mich in ein schlechtes bild aber wer ist wohl eher schuld, der der diese schlechte Einschätzung bekommt oder ide die sie vermittelt haben hust