Der Titel ist ja schon ein wenig Klickbait. 
Natürlich sollte die Masse an Tests immer nur einen bestimmten Aspekt testen. Das sind in der Regel Unittests (oder wie er sagt isolated tests). Aber ob die ganzen Units auch wirklich zusammen arbeiten, kann eigentlich nur ein übergreifender Test wirklich sicherstellen.
Ich habe mir angewöhnt, zumindest für die kritischen Fälle einen (in der Regel Happypath) Test zu schreiben. Damit weiß ich zumindest, dass die Komponenten im Regelfall zusammenarbeiten.
Ich halte es ziemlich ähnlich wie du - nur dass ich versuche in jedem Fall einen IT für den Happypath zu haben. Sowohl privat als auch im Betrieb. Und ich freue mich jedes mal wieder drüber, wenn ich einen test schreiben kann, bevor ich die Story implementiere. Wenn man mal raus hat, wie man solche Tests schreibt, dann gehen die meistens auch extrem flott von der Hand. Und nicht jedes mal die komplette Applikation starten zu müssen um sich durchzuklicken ist dann eine erhebliche Zeitersparnis.
Und privat nun ja. Ich hab keinen QA der meine App testet. Da bin ich von daher gesehen froh um jeden automatisierten Test den ich habe.
Bei uns in der Firma sind uns die Integration-Tests über den Kopf gewachsen, ähnlich wie im Video geschildert. Wir haben auch “Long running integration tests”, und - das ist kein Witz - da darf man tatsählich über 5 Stunden warten.
Wie in den meisten Fällen liegt die Wahrheit in der Mitte, aber aus meiner Sicht macht der Herr einen validen Punkt.
Bei einem ehemaligen Arbeitgeber von mir wird seit 30 Jahren eine Rechensoftware entwickelt die wahrscheinlich über ~2^[dreistellig] Zustände hatte. Jeden Monat, wenn eine neue Version herauskam, haben sich 4 Ingenieure 4/5 Tage lang hingesetzt und eine Exceltabelle mit Inputparametern und Ergebnissen manuell durchgetestet. Alle von den Kunden entdeckte Fehler wurden behoben und in die Liste aufgenommen. 30 Jahre lang. Das war weder Effizient noch sicher.
Ein Integrationtest von mir hat die dokumentierten Tests in ein paar Minuten durchgetestet.
Der Typ im Video spricht davon, dass das Problem ist die ganzen Tests zu schreiben. Nö. Das Problem ist, dass selbst eine Serverfarm ein paar Milliarden Jahre benötigen würde um alle Tests durchzurechnen.
Ich hab jetzt nicht verstanden wie seine Lösung dazu beitragen kann, dies zu verbessern. Aber vielleicht hab ich mir auch das falsche Projekt rausgesucht.
Wir brauchen ca. 120 „Maschinen“ (AWS, Docker-in-docker) fuer einen einzigen branch build, viel zu viele langsame Integrationstests, viel zu wenig Unit test, da der Code nicht „unit testable“ ist… klar koennten wir auch nur mit einer Maschine bauen, aber das wuerde sehr lange dauern, mit dem 120 „Agenten“ sind das so zwischen 60-80 minuten… 
Sprichst Du von Atlassian?
Immerhin kann man dazu sagen, dass diese Tests schon automatisiert laufen. Schlimmer wäre es wohl noch, diese manuell auszuführen
Kann ich weder bestaetigen noch verneinen 
Das Problem ist wirklich dass wenn die Balance mal verloren gegangen ist, man fast nur noch Integrationstests schreiben kann (anstatt 15 mocks fuer einen einzigen Unit test), ganz zu schweigen von der „Test Kultur“ die sich etabliert hat.
Gilt alles nur fuer die „alten“, grossen Projekte/Produkte, mit den neuen MicroServices macht man das anders.
In anderen Firmen, wo man nicht soviel Geld hatte um Tests auszufuehren, ist man irgendwann auf den Trichter gekommen Prod- & Testcode zu refaktoren.
Naja, wenn man 15 Mocks benötigt, um einen Test schreiben zu können, ist es vielleicht auch geeigneter dafür einen Integrationstest zu schreiben. Vielleicht sollte man bei der Anzahl der Abhängigkeiten einfach anfangen.
Aber klar, am Ende ist es immer eine Sache, wieviel Geld investiert werden darf.
Das Design des legacy codes ist schon lange nicht mehr testbar mit unit tests, zumindest nicht ohne unverhaeltnissmaessig grossen Aufwand.
Wenn man genug Budget hat fuer die integrations test infrastruktur, ist es schwer zu argumentieren dass man den prod code & test code refaktoren monatelang refaktoren sollte… leider
Das ist traurig, leider häufig aber immer noch die Regel. Bis irgendwann ein Produkt auf den Markt kommt, welches schneller neue Features bereitstellt. Immerhin kommt das nicht allzu häufig vor, bzw. als großer Laden kann man das Produkt ja einfach aufkaufen.
Aber das ist hier Offtopic