Ich arbeite in einer Firma, in der OOP ... na ja, nicht verboten, aber zumindest als "zu komplex" verpönt ist. Meine Mitarbeiter schreiben viele über 100 Zeilenfunktionen und sie befinden sich meist alle in einer "funcs.inc.php" oder "something.inc.php", wenn sie überhaupt irgendwelche Funktionen verwenden, oft nicht seit copy-paste schneller.
Ich würde gerne anfangen, TDD zumindest für den Code, den ich schreibe, zu verwenden, aber da ich mit ihrem Code interagieren muss, kann ich nicht sehen, wie ich anfangen soll.
Es ist kein Legacy-Code, da sie aktiv entwickelt werden und ich möchte ihren Code nicht ändern, da ich keine Konflikte provozieren möchte.
Welchen Ansatz würden Sie vorschlagen, außer die Firma zu wechseln?
Ich war in dieser Position, sowohl in einer von der tatsächlichen TDD. Normalerweise schreibe ich Tests für die Schnittstellen anderer Leute, wann immer es möglich ist. Ich weiß dann, bevor ich meinen Code ausführe, wenn sie eines der vielen üblichen Dinge tun, die Leute tun:
Jeder dieser Fehler würde normalerweise dazu führen, dass ich sage "Hey, kannst du nachschauen (Modul), ich denke, es ist in der letzten Überarbeitung gebrochen"
Das wurde nur einmal hässlich. Jemand anderes wurde wirklich sauer, dass ich Tests für ihren Code schrieb und darauf bestand, dass ich für ihren Job war. Ich konnte die Person nicht verstehen lassen, dass ich einfach nur meine Arbeit erleichtern wollte.
Es ist nie eine gute Idee, gleich rauszukommen und zu sagen: "Schau, ich verbringe mehr Zeit damit, deinen Code zu debuggen, als alleine zu arbeiten", es sei denn, du musst unbedingt (d. h. dein Chef fragt nach deiner Leistung). Meistens, wenn Sie den Test einfach den Leuten schicken, sind sie glücklich, sie zu haben. Wenn Sie bereits Widerstand gegen die Idee finden, versuchen Sie einfach niemanden zu beleidigen oder herablassend zu wirken.
Mock-Funktionen / Stubs sind in Ordnung, aber was bleibt, ist, dass das Programm als Ganzes immer noch bricht, wenn echte Tests nicht ausgeführt werden. Zumindest wenn das passiert, kannst du deine Sachen schnell ausschließen und (wahrscheinlich) auf das Problem zeigen.
Verwenden Sie TDD für alle Ihre Module und schreiben Sie Tests, wenn Sie ihre Module für etwas verwenden. Schließlich werden alle anderen bemerken, dass Sie qualitativ hochwertigen Code viel schneller als jeder andere produzieren, und sie werden neugierig sein, warum. Das wird die perfekte Gelegenheit sein, sie zu erziehen.
Wenn sie nie fragen, naja, zumindest hast du dein Leben ein bisschen einfacher gemacht.
Ich würde vorschlagen, mit dem nächsten zu beginnen, was Sie schreiben müssen und zuerst einige Tests zu machen und dann den Code für das Ding zu schreiben. Es könnte einen Fehler beheben, eine Erweiterung oder ein neues Feature implementieren, aber die Idee besteht darin, einen Weg zu finden, die Tests vor der Änderung durchzuführen.
Alternativ könnten Sie einige Ihrer Mitarbeiter Code nehmen und Tests um einige davon wickeln und versuchen, es zu refaktorisieren, aber ich bin mir nicht sicher, wie gut das geht.
Wahrscheinlich möchten Sie Ihren Code isoliert von seinem Code testen. Dies wird ändern, wie Sie Ihren Code entwerfen - aber das ist wahrscheinlich, warum Sie TDD sowieso tun möchten.
Erstellen Sie Mock-Funktionen für die Bibliotheken, aus denen Sie sich isolieren möchten.
Können Sie zuerst Unit-Tests mit Ihrem eigenen Code schreiben? Ärgere dich nicht von anderen Leuten; Stellen Sie sicher, dass Ihr Code vollständig getestet und getestet wurde.
Um die Interaktion mit anderen Bibliotheken zu simulieren, können Sie die bewährten Techniken wie Mocks und Stubs ausprobieren.