Wenn Unit-Tests so großartig sind, warum machen es dann nicht mehr Unternehmen? [geschlossen]

Das erste echte Softwareunternehmen, bei dem ich gearbeitet habe, war das Unit Testing (NUnit). Ich weiß nicht, dass wir damals echte Stickler dafür waren - ich habe keine Ahnung, wie unsere Codeabdeckung war, und ich habe die meisten Unit-Tests geschrieben. Seitdem bin ich auf einige Unternehmen gestoßen, die viele Tests durchführen, aber es handelt sich um Stuhlprüfungen: Sie sind darauf angewiesen, dass eine Person dort ist, haben eine geringe Wiederholbarkeit und eine geringe Wahrscheinlichkeit, Fehler zu erkennen. Die andere Einstellung ist: Es war etwas, mit dem sie "in der Zukunft" beginnen wollten; im Grunde, wenn Geld vom Himmel fällt.

Ich vermisse Unit-Tests - das macht das Leben einfach einfacher. Aber ich stelle fest, dass Unit-Tests bei der Suche nach einem neuen Job entweder etwas sind, mit dem Unternehmen in Zukunft "loslegen" möchten, oder etwas, das sie überhaupt nicht tun (ähm, es gibt es schon eine Weile jetzt!). Ich würde sagen, dass 60-75% der Jobanforderungen, die ich mir in den letzten 2 Jahren angesehen habe, überhaupt keine Unit-Tests aufgeführt haben. Ich kann mir nur ein oder zwei vorstellen, die Erfahrung mit Unit-Tests als Voraussetzung hatten (für eine mittlere Entwicklerposition).

Die Frage ist also, was fehlt ? Ich denke, es macht die Leute produktiver, aber das ist erst, nachdem man eine solide Zeit damit verbracht hat, es tatsächlich zu tun. Gibt es keine guten Studien zu den Kosteneinsparungen bei Unit-Tests? Ist es die Art von Unternehmen, die ich betrachte?

Bearbeiten: Obwohl der Titel ein bisschen Teufelsanwalt ist, betrachte ich mich als Befürworter von Unit-Tests.

Nach meiner Erfahrung sind hier einige Faktoren beteiligt:

1. Das Management versteht nicht wirklich, was Unit-Tests wirklich sind oder warum sie für sie einen echten inneren Wert haben.
2. Das Management befasst sich eher mit der schnellen Produktlieferung und sieht Unit-Tests (fälschlicherweise) als kontraproduktiv für dieses Ziel an.
3. Es gibt eine falsche Vorstellung, dass das Testen ausschließlich zur Qualitätssicherung gehört. Entwickler sind Programmierer und können keine Tests schreiben.
4. Es gibt eine verbreitete Fehleinschätzung, dass das Management Geld ausgeben muss, um Unit-Tests korrekt durchzuführen, obwohl die Tools frei verfügbar sind. (Natürlich muss der Entwickler die Anlaufzeit in Betracht ziehen, aber das ist nicht wirklich unerschwinglich.)
5. Wills Antwort wird diese Antwort abrunden: Es ist sehr schwer, den Wert des Testcodes zu bestimmen (jcollum bearbeiten)

Natürlich gibt es noch andere Faktoren, aber genau darauf bin ich bisher gestoßen.

1) Es ist schwer
2) Es braucht Zeit
3) Es ist sehr schwer, den Wert des Testcodes zu bestimmen

Punkt 3 ist klebrig. Gute Unit-Tests reduzieren Fehler. Aber auch guter Produktionscode. Wie stellen Sie fest, wie viele Fehler aufgrund Ihrer Komponententests nicht vorhanden sind? Sie können nicht messen, was nicht existiert. Sie können auf Studien verweisen, diese passen jedoch nicht gut in die Tabelle Ihres Geschäftsmanagers.

Es ist leicht, dem „Management“ die Schuld zu geben. Aber ist das Management wirklich sagen , Sie speziell nicht jede Unit - Tests zu tun?

Das Management im Allgemeinen sagt Ihnen nicht (und sollte es wahrscheinlich auch nicht), wie Sie Ihre Arbeit erledigen sollen, ob es sich um Modularisierung, abstrakte Datentypen, Entwurfsmuster oder Komponententests handelt. Dies sind Handelsinstrumente, die ein erfolgreicher, kompetenter Softwareentwickler anwendet, ein schlechter Ingenieur jedoch nicht.

Ich denke, die eigentliche Antwort auf Ihre Frage lautet: Unit-Tests sind wirklich schwierig, und Informatikstudenten sind nicht dafür ausgebildet.

Es ist einfach, wenn Sie Ihre eigene String-Klasse schreiben. Wenn Sie ein reales Produkt testen, stoßen Sie auf Herausforderungen, von denen Ihnen in den PowerPoint-Folien niemand erzählt hat:

• Benutzerinteraktion. Die Hälfte Ihrer Anwendung ist die Benutzeroberflächenlogik. Wie testest du es auf automatisierte Weise, die nicht kaputt geht, wenn du einen Knopf bewegst?
• Interaktion mit externen APIs und Frameworks. Wie testen Sie einen Windows-Kerneltreiber, wenn Sie ihn schreiben? Schreiben Sie Stubs für jede von Ihnen verwendete IRP- und Kernelfunktion, um effektiv eine Simulation des Betriebssystemkerns zu erstellen?
• Netzwerkkommunikation ist das Ding des 21. Jahrhunderts. Wie koordinieren Sie einen Komponententest, der aus mehreren verteilten Komponenten besteht?
• Wie wählen Sie gute Testfälle aus? Ich sehe häufig Leute, die versuchen, zufällige Dinge in einer Schleife von 1000 Iterationen zu tun und zu sehen, ob sie kaputt gehen. Wenn Sie dies tun, ist der Aufwand höher als die Rendite, wichtige Fehler werden übersehen und Unit-Tests werden abgebrochen.
• Wie testen Sie, ob die Leistungsanforderungen erfüllt sind?
• Das Wissen über Muster beim Testen ist knapp: Stubs, vordefinierte Antworten und Regressionstests sind Konzepte, die die meisten Menschen nicht kennen. Wie viele an Ihrem Arbeitsplatz lesen tatsächlich ein Buch über Unit-Tests?

Das eine, wofür wir das Management verantwortlich machen können, ist, dass Anforderungsspezifikationen selten Anforderungen an das Qualitätsniveau des Liefergegenstandes enthalten.

Wenn Ihr Chef Sie das nächste Mal auffordert, eine Zeitschätzung vorzunehmen, geben Sie die Zeit für das Schreiben eines Komponententests an und sehen Sie, was passiert.

Die meisten Tests testen nichts.
Sie schreiben eine fileopen () - Funktion und eine unittest, die fehlschlägt, wenn die Datei nicht vorhanden ist, und erfolgreich ist, wenn die Datei vorhanden ist. Toll! Haben Sie jetzt überprüft, ob es mit dem Dateinamen in BIG5 Chinesisch funktioniert? auf einer NFS-Freigabe? auf Vista mit der Datei auf einem USB-Stick und UAC eingeschaltet?

Das Problem ist, dass die Komponententests von demselben Programmierer geschrieben werden, der die Funktion geschrieben hat, mit denselben Annahmen und denselben Fähigkeiten. Um wirklich zu funktionieren, müssen die Tests von jemand anderem geschrieben werden, nur nach den veröffentlichten Spezifikationen, ohne dass dieser den Code sieht. - In den meisten Unternehmen wäre es ein Durchbruch, nur schriftliche Spezifikationen zu erhalten!

Unit-Tests prüfen, ob der Code der einzelnen Funktionen fehlerhaft ist. Sie können für Datenzugriffsebenen, Mathematikbibliotheken usw. verwendet werden, bei denen die Ein- / Ausgänge bekannt sind und die interne Struktur komplex ist, aber in vielen Fällen sind sie nur Zeitverschwendung.
Sie schlagen fehl, wenn die Fehler auf Interaktionen zwischen verschiedenen Codeteilen oder mit dem Betriebssystem und dem Benutzer zurückzuführen sind. Probleme wie hohe / niedrige DPI-Einstellungen, die ein Dialogfeld durcheinander bringen, oder eine Fremdspracheneinstellung, bei der ein '.' und ',' werden normalerweise nicht gefunden.

Es wurden Studien zum ROI von Unit-Tests durchgeführt - siehe diese Frage .

Ich habe viele Entwickler gefunden, die nicht an Unit-Tests interessiert sind. Es scheint immer viel Arbeit mit wenig Gewinn zu sein, wenn Sie anfangen. Niemand möchte sich für zusätzliche Arbeit anmelden und widersetzt sich daher. Sobald die Leute anfangen, bleiben sie normalerweise begeistert dabei, aber es kann schwierig sein, sie anzufangen.

Abgesehen von der Frage der Einführung von Unit-Tests lohnt sich Unit-Test nicht immer, obwohl ich es im Allgemeinen denke, wenn es richtig angewendet wird. Unit-Tests sind nichts Besonderes, das sie davor bewahrt, für schlechte Konstruktionen anfällig zu sein.

Unit-Tests haben Kosten (Erstellung, Wartung und Ausführung) und sind nur dann sinnvoll, wenn sie einen größeren Nutzen als diese Kosten bieten. Das Erstellen von Tests ist eine Fähigkeit wie jede andere. Sie erfordert spezifische Erfahrung und Kenntnisse, um erfolgreich zu sein. Ohne ausreichende Erfahrung ist es selbst für ansonsten erfahrene Entwickler sehr einfach, Unit-Tests von geringer Qualität, geringem Wert und / oder hohen Kosten zu erstellen, die sich nicht lohnen. Vor allem, wenn man bedenkt, wie schwierig es sein kann, den Wert eines Unit-Tests zu beurteilen.

Darüber hinaus sind Unit-Tests nur eine Möglichkeit, die Codequalität zu verbessern, aber nicht die einzige. Unter bestimmten Umständen und bei einigen Teams ist dies möglicherweise nicht der effektivste Weg, um die Qualität von Software zu verbessern.

Denken Sie daran, dass ein großer Aufwand für Unit-Tests keine Garantie für hochwertige Software ist. Und es ist auch möglich, Software von höchster Qualität ohne jeglichen Unit-Test zu produzieren.

Nun, meine Firma hat sich nicht für TDD oder Unit Testing entschieden. Um ehrlich zu sein, sind wir uns nicht sicher, wie wir das machen sollen. Wir können es natürlich für dumme Funktionen wie CapitalizeString () usw. tun, aber wir wissen nicht, wie wir es für hochkomplexe Systeme mit komplizierten Objekten tun sollen. Darüber hinaus haben die meisten Befragten entweder keine oder nur begrenzte Erfahrung. Es scheint, dass Unit Testing von der SO-Masse groß ist, aber im verfügbaren Workpool nicht besonders groß.

TDD ist ein separates Thema. Wir sind moralisch gegen TDD. Wir sind keine Cowboy-Programmierer, aber wir glauben, dass dies Kreativität und Flexibilität in einem Projekt beeinträchtigt. Darüber hinaus macht es keinen Sinn, den Codierer zu haben, der die Unit-Test-Funktion geschrieben hat. Wenn ich etwas mache, codiere ich alle Randfälle, die mir einfallen. Was ich brauche, ist ein anderes Gehirn, um nach Dingen zu suchen, die ich möglicherweise übersehen habe. Das haben wir nicht. Die Teams sind klein und eigenständig.

Kurz gesagt, wir glauben nicht an TDD, aber wir möchten Unit Test. Wir haben einfach nicht die Erfahrung dazu und können es nicht leicht finden.

Es gibt viele Unternehmen, die wirklich nichts im Sinne von Best Practices tun. Keine Codeüberprüfungen, keine Unit-Tests, keine Testpläne, kein Nichts, nur am Sitz ihrer Hose.

Nutzen Sie diese Gelegenheit, um sie dazu zu bringen, eine Continuous Integration-Plattform zu nutzen und Unit-Tests zu entwickeln! Einfache Möglichkeit, die vorhandenen Kräfte zu beeindrucken und gleichzeitig die Qualität und Stabilität Ihres Codes zu verbessern

Bearbeiten: Aus gutem Grund denke ich, dass sie einfach nicht über die aktuellen Tools informiert sind, die CI- und Unit-Tests außerordentlich einfach machen.

Ich denke nicht, dass Faulheit die Hauptursache für schlechte Unit-Tests ist. Für mein Unternehmen sind Zeitbeschränkungen und die Einstellung "Einfach erledigen" die größten Abschreckungsmittel für Unit-Tests. Außerdem befinden sich die Stellen, an denen unsere Systeme ausfallen, eher auf der Integrationsebene (Dienste, Datenbankzugriffe, komplexe Abfragen, für die bestimmte Daten zum Testen erforderlich sind) als auf der "Einheitenebene". Diese Dinge sind nur schwieriger zu testen, und wenn Sie kaum genug Zeit haben, um die Funktion auszuführen, haben Sie wahrscheinlich keine Zeit, um gleichzeitig nützliche Tests durchzuführen.

Unit-Tests sollten genau wie der Compiler nur ein natürlicher Bestandteil des Code-Entwicklungs-Workflows sein.

Dies erfordert jedoch eine Schulung des Managements über die Vorteile der Unit-Tests. Nachwuchsentwickler haben jedoch relativ geringe Chancen, einen solchen Einfluss zu haben. Ob ein Unternehmen ein Befürworter des Unit-Tests ist, hängt daher davon ab, ob es einen leitenden Entwickler oder Architekten hat, der sich für Unit-Tests einsetzt.

Ich glaube, dies ist die Antwort auf Ihre Frage "Was fehlt und warum führen nicht mehr Unternehmen Unit-Tests durch?" . :-)

Es ist wahrscheinlich eine Kombination aus ein paar Dingen, die Sie bereits erwähnt haben. Es ist schwierig, die Kosteneinsparungen von TDD zu messen. Wenn Sie Ihre IT auslagern möchten, können Sie zeigen, wie viel Sie pro Jahr für die Mitarbeiter bezahlen, die Sie beschäftigen, im Vergleich zu den Kosten für die Auslagerung. Es ist sehr konkret. Wie sagt man: "Oh, dieser Test hat einen Fehler entdeckt, für dessen Debugging und Behebung ich 4 Stunden gebraucht hätte ..."?

Der Grund, warum einige Orte es nicht verwenden, ist einfach, dass es viel Arbeit erfordert, um loszulegen und fortzufahren. Die Tatsache, dass das Schreiben von Komponententests ungefähr so ​​viel Zeit in Anspruch nimmt wie das Schreiben der eigentlichen Funktionalität, scheint einigen Managern, als würden Sie die Produktivität Ihres Entwicklers halbieren.

Darüber hinaus muss ein Team (oder jemand) die Infrastruktur einrichten und warten.

Und wie Alan sagt, verwenden viele Orte einfach keine Best Practices - sie wollen nur etwas Greifbares sehen.

Nach allem, was ich gesehen habe, haben viele Unternehmen riesige, stark gekoppelte Codebasen, die praktisch nicht auf Einheiten getestet werden können. Sie haben auch keine anständigen testbaren Anforderungen, so dass die Unit-Tests gegen "wie gebaut" de facto Anforderungen testen würden.

Ich denke, dass der Programmierer einfach damit anfangen muss. Einige einfache Tests sind im Rahmen der Entwicklung leicht zu rechtfertigen.

So etwas wie ein Unit-Test ist fast immer notwendig, um ein schnelles Debuggen zu erreichen. Erklären Sie einfach, wie viel schneller es ist, den Test zu starten, als die richtige Eingabe zu arrangieren, einen Debugger-Haltepunkt festzulegen, die Anwendung zu starten usw.

Dokumentieren Sie den Test in Ihrem Code. Geben Sie einfach einen Kommentar ein, in dem erläutert wird, wo sich der Test befindet und wie er ausgeführt wird. Zukünftige Programmierer werden es sehen und hoffentlich werden sich die Tests verbreiten!

Unit-Tests sind einer der Black-Box-Begriffe, die die meisten Menschen gehört haben, wissen aber nicht, was genau einen Unit-Test ausmacht, wo sie beginnen sollen, wie sie geschrieben werden sollen, wie Tests tatsächlich ausgeführt werden sollen, was genau sie testen sollen usw. usw. usw. usw.

In vielen Fällen ist es für den unsicheren Entwickler einfacher, sie einfach als unnötig oder als Sahnehäubchen abzutun, das nur Entwickler auf Unternehmensebene benötigen.

Ich bin ein großer Fan von Unit-Tests und Partner eines Unternehmens, das Vertragsentwicklungsprojekte für verschiedene Kundentypen durchführt. In einem Monat werden wir 3-4 verschiedene Projekte unterschiedlicher Größe berühren.

Wenn ein Projekt einmalig zu sein scheint, werde ich nicht viel in Unit-Tests investieren, da sich diese Unit-Tests für mein Unternehmen nicht auszahlen. Bei solchen Projekten werde ich Dinge testen, die mir unsicher / unbekannt sind oder die sich häufig ändern können (z. B. ein Parser für eine Datenquelle, die ich nicht kontrolliere).

Wenn ich etwas baue, von dem ich weiß, dass es eine lange Lebensdauer hat, eine größere Arbeit ist, mit der ich durch mehrere Iterationen arbeiten werde, oder die einen großen Einfluss auf meine Kunden hat, wenn ein Fehler auftritt Ich werde in mehr Unit-Tests investieren. Wieder dreht sich die Priorität der Tests um unsicheren / unbekannten / sich ändernden Code.

Ich denke, Unit-Tests sollten sich um die Komplexität einer Aufgabe drehen und darum, ob sie sich auszahlen. Es macht keinen Sinn, zusätzlichen Code zu schreiben, der nicht verwendet wird.

Nach meiner Erfahrung hängt es wirklich von der Software ab, die Sie schreiben. Ich habe festgestellt, dass es extrem schwierig ist, Komponententests für eine Benutzeroberfläche zu schreiben. Ich verwende Unit-Tests nur für Teile des Systems, die ein bestimmtes In / Out haben.

Ich vermisse Unit-Tests - das macht das Leben einfach einfacher.

Das ist nicht , wirklich, ein ausreichender Grund für ein Unternehmen , Unit - Tests zu übernehmen.

Ein ausreichender Grund könnte "billiger" (und / oder "besser") sein: Dies ist bei Unit-Tests nicht so einfach zu beweisen.

Der einzige gute Grund könnte sein, dass "das Schreiben von Komponententests die beste Nutzung der Entwicklerzeit ist", was IMO wirklich schwer zu beweisen ist: und es kann an einigen Stellen zutreffen, für einige Software, mit einigen Entwicklern und anderswo nicht.

Es gibt viele Entwickler, die die Welt der Unit-Tests nicht glauben: Einige denken, dass andere Testformen (z. B. automatisierte Integration / Funktionstests) billiger und wertvoller sein könnten, zum Beispiel bin ich der einzige Entwickler, der dies nicht tut. Sie mögen keine Unit-Tests?

Natürlich kann man in der idealen Welt nicht gegen einen Unit-Test argumentieren.

Ob Sie einen Komponententest schreiben, hängt jedoch von einer Reihe von Faktoren ab:

• Wie die Software verwendet wird. Wenn Sie Software nur für sich selbst schreiben würden, würden Sie Unit-Tests schreiben? Wahrscheinlich nicht. Wenn Sie vorgefertigte Software für den kommerziellen Verkauf geschrieben haben, wahrscheinlich ja.

• Wie viele Personen pflegen den Code? Wenn Sie es nur sind, wissen Sie ihn möglicherweise gut genug, um nach einer Änderung sicher genug zu sein, dass ein schneller Durchlauf des Codes ausreicht, um sicherzustellen, dass nichts kaputt gegangen ist. Wenn andere Personen, die den Code ursprünglich nicht geschrieben haben, ihn jetzt beibehalten müssen, können sie durch einen Komponententest sicher sein, dass sie beim Aktualisieren des Codes zur Behebung eines großen Problems (das offensichtlich nicht im Komponententest erfasst wurde!) Nichts beschädigt haben .

• Codekomplexität: Nur Testcode, der einen Test benötigt. Eine einzeilige Variablenzuweisungsmethode muss nicht getestet werden. Eine 50-Zeilen-Methode mit mehreren Ausführungspfaden ist wahrscheinlich ausreichend.

• Praktische kommerzielle kommerzielle Überlegungen: Das Schreiben von Unit-Tests dauert länger als das Nicht-Testen. Wenn Sie Prototyp-Software schreiben, die eine ungewisse kommerzielle Zukunft hat, dann lohnt es sich, schnell Code zu haben, der ausreichend gut funktioniert, und in 2 Wochen Unit-getesteten Code, der besser funktioniert. Manchmal lohnt es sich, schnell herauszufinden (Appetit der Verbraucher), ob Software ein kurzes Regal hat, und mit dem nächsten Projekt fortzufahren.

und wie andere betont haben, ist ein Test nur so gut wie die Person, die ihn geschrieben hat.

Der Hauptgrund ist, dass viele Entwickler und Entwicklungsmanager keine Ahnung haben, ob Unit-Tests existieren oder wie sie verwendet werden.

Der zweite Grund ist, dass Unit-Tests nur (auf sinnvolle Weise) mit Code verwendet werden können, der bereits einige Qualitätsstandards erfüllt. Es besteht die Möglichkeit, dass eine vorhandene Codebasis nicht in diese Kategorie fällt.

Der dritte Grund ist Faulheit und / oder Billigkeit.

Weil Unit-Tests nur dann nützlich sind, wenn Sie testbaren Code schreiben. Und das Schreiben von testbarem Code ist schwierig. Und die Leute sind faul und / oder billig.

EDIT: nuanciert "faul" als "faul und / oder billig"; In einigen seltenen Fällen verfügen die Leute tatsächlich über die Fähigkeiten und die Fähigkeit und den Willen, Tests zu schreiben, aber sie haben noch etwas zu tun, das sich direkter auf das Endergebnis auswirkt.

Ich denke, ein Teil des Problems besteht darin, dass Entwickler von Geschäftsleuten erwarten, dass sie dieselben Werte haben und sich wirklich um die Antwort auf "Sollen wir Unit-Tests durchführen oder nicht?" Kümmern. Wir erhalten keine vorherige Genehmigung vom Unternehmen, eine Hochsprache anstelle einer Assemblersprache zu verwenden - dies ist normalerweise nur der vernünftige Weg, um die Arbeit zu erledigen.

Der Punkt ist, dass wir die einzigen sind, die für den Anruf qualifiziert sind (was nicht heißt, dass wir alle das gleiche Wissen über das Thema haben). Selbst wenn Ihr Team aus politischen Gründen keine Unit-Tests durchführt (oder Ihre Tagesmethode benennt), bedeutet dies im Allgemeinen nicht, dass Sie dies nicht tun können.

Die Wahrheit ist, dass wir den ROI für die meisten Dinge, die wir tun, nicht wirklich mit einer zu feinen Granularität beweisen können. Warum Unit-Tests diesem unvernünftigen / untypischen Beweisstandard standhalten, ist mir ein Rätsel ...

Die Leute sind faul und nehmen Veränderungen nur an, wenn sie dazu gezwungen werden.

Meine 2 Cent:

• Es erfordert etwas Ausbildung und Disziplin, aber neue Absolventen verfügen bereits über die richtigen Kenntnisse.
• Der Testaufwand kann mit besseren Tools reduziert werden, und dies geschieht auch (Refactoring usw.)

Es ist also nur eine Frage der Zeit.

Es gibt die Martin-Coplien-Debatte, in der Bob Martin Folgendes behauptet:

"Heutzutage ist es für einen Entwickler unverantwortlich, eine Codezeile zu versenden, die er in einem Komponententest nicht ausgeführt hat."

[ http://www.infoq.com/interviews/coplien-martin-tdd]

Wenn Sie alle beim Testen verkaufen möchten, gehen Sie wie folgt vor:

1. Schreiben Sie eine Reihe von Tests.
2. Benachrichtigen Sie die anderen Entwickler, die den Code ändern und Ihre Tests nicht bestehen.
3. Sie werden ihren Code reparieren.
4. Jetzt können Sie ohne diese besonderen Fehler veröffentlichen.

Sogar ein Manager könnte das verstehen.

Unternehmen führen keine Unit-Tests durch, aus dem gleichen Grund, dass viele Websites schlecht geschrieben sind - Unwissenheit und Menschen, die an alten Gewohnheiten festhalten. In unserem Unternehmen erreichen wir seit Beginn der Unit-Tests (mit Nunit und Typemock ) eine höhere Codeabdeckung und veröffentlichen die Software in kürzerer Zeit auf den Markt.

Wie die meisten guten Ideen hat die Annahme mehr mit der Abhängigkeit von Organisationspfaden als mit der Qualität der Idee zu tun.

In den meisten Unternehmen, die Produkte ausgeliefert haben, wurde eine umfangreiche QS-Abteilung mit einem leitenden QS-Leiter eingerichtet. Testen ist das Lehen des QS-Teams.

Es ist unwahrscheinlich, dass das QA-Team Unit-Test-Code schreibt, da das Unternehmen das QA-Team normalerweise nicht mit seinen Hochleistungscodierern besetzt.

Das Programmierteam zögert, Testcode zu schreiben, da dies zu einem Konflikt mit dem QS-Team führt.

Ich habe mehr Interesse und Akzeptanz von Unit Testing in Gruppen gesehen, in denen die Qualitätssicherung nicht in eine separate Jobfunktion ausgegliedert wurde

Das Schreiben und Aktualisieren von Komponententests kostet einfach Geld. Die meisten früheren Softwareprogramme von Unternehmen haben keine Komponententests und kosten zu viel für das Schreiben. Sie tun dies also nicht und es verlängert den Entwicklungsprozess, sodass sie es auch nicht zu neuen Funktionen hinzufügen.

Die meisten Unternehmen sind nutzlos. Offensichtlich nicht der, für den Sie (oder ich) arbeiten.