Code testen vor dem Einchecken



  • Ich hab heute in unserem Code schon wieder eine Stelle gefunden, die zum Crash führt, sobald sie durchlaufen wird. Es ist ganz offensichtlich, dass der der das eingecheckt hat, seinen Code nie ausprobiert hat. Wie ist das bei euch, wird da auch sowas eingecheckt?

    PS: Firmengröße zwischen 50 und 100 Entwickler.



  • Naja, Firmengröße wird ja nicht Projektgröße heißen, oder? Wenn 100 Leute in ein Projekt einchecken dürfen, ist da ja schon mal der Fehler. Dann muß es jemanden geben, der den Code vorher begutachtet und nur der Gutachter selber einchecken darf.

    An sonst ist es in unserem Projekt (handhabt jedes Projekt in unserer Firma anders) so, das der Entwickler auscheckt, die autom. Tests laufen lässt, das Pre-Protokoll an den Change Request als Datei anhängt, seine Änderungen macht, dann autom. Tests laufen lässt und das Post-Protokoll an den CR anhängt. Und dann darf er einchecken, wenn die Post-Tests natürlich gut sind.

    Das ist aber nur ein Verfahren. Vor allem dieses anhängen vom Testprotokoll ist fragwürdig... außer man will als Entwickler dokumentieren, das ein Fehler schon vorher drin war, und man selber unschuldig ist. 😃

    Am besten ist aber Continuous Integration:
    http://de.wikipedia.org/wiki/Kontinuierliche_Integration
    Entscheidend ist, das Continuous Integration autom. auf einem Server läuft. Ob das nach jedem Check-in oder z.B. zur Mittagspause läuft, ist vom Projekt abhängig. Und dann wird man autom. über Ergebnisse informiert, z.B. per E-Mail.



  • Also bei uns passiert das auch hin und wieder.

    Grundsätzlich sollte es nicht, da jeder Entwickler seine Änderungen erstmal lokal testen sollte, aber das wird halt nicht immer gemacht.

    Finde ich auch nicht SO tragisch, da wir nicht auf einen 100% stabilen Trunk hinarbeiten.
    Lästig ist es natürlich, aber naja.

    Strukturen/Abläufe die sowas zum Grossteil verhindern sind halt sehr aufwendig. Oft steht da der Nutzen nicht für den zusätzlichen Aufwand. Wobei das natürlich auf die Art des Projektes ankommt. Je schlimmer (=teurer) Bugs sind, desto eher wird es sich auszahlen.



  • Wenn jemand einen Fehler eingecheckt hat, geht man halt zu dem Übeltäter rüber, und "redet" mal mit ihm. Wenn ihr versteht was ich mein?! 😉 😃

    Nein, im Ernst. Wenn sowas passiert, hat kann man ja mal rüber gehen, und mit ihm ein Wörtchen reden. 😃

    Neee, nicht so! Also, man greift einfach zum Telefon, und bittet ihn, doch mal den Fehler zu beheben. Aber persönlich ist immer noch am besten.

    Oder man machts gleich selber... aber das empfinde ich nicht für so gut, weil dann der Kollege sich bloß gestellt fühlen könnte.

    Meine Erfahrung ist, das im Trunk doch eher selten wirklich offensichtliche Fehler eingecheckt werden. Weil doch halt jeder vorher in seinem Branch arbeitet. Vielleicht passieren bei euch so viele Fehler, weil ihr keine Developer-Branches habt?



  • Ja, wir entwickeln das meiste direkt im Trunk.

    Für grössere Sachen werden Feature-Branches gemacht. Wenn dann allerdings mehr als eine Person an so einem Feature arbeitet is es ja wieder das selbe: man ärgert sich wenn ein anderer etwas eincheckt was nicht funktioniert.

    Ich sehe das auch alles nicht so eng. Wie gesagt: fast alles was da die Fehleranfälligkeit verringert hat seine Kosten.

    Allerdings ist mir auch klar, dass es von sehr vielen Faktoren abhängt was die beste Vorgehensweise bezüglich Branchen, Unit-Tests, Continuous-Integeation etc. ist.

    Oder man machts gleich selber... aber das empfinde ich nicht für so gut, weil dann der Kollege sich bloß gestellt fühlen könnte.

    Ja, das dachte ich mir auch immer. Trifft aber - wie so ziemlich alles auf der Welt - nicht auf alle zu. Einige gibt es, die fühlen sich eher genervt oder sogar ans Bein gepinkelt, wenn man ihnen ne Mail schreibt dass XYZ nicht funktioniert. Speziell wenn der Fehler/die nötige Änderung offensichtlich ist.

    p.S.: ich sage auch gar nicht dass es "oft" vorkommt, ich sagte es passiert hin und wieder. 😉



  • hustbaer schrieb:

    Strukturen/Abläufe die sowas zum Grossteil verhindern sind halt sehr aufwendig. Oft steht da der Nutzen nicht für den zusätzlichen Aufwand.

    Wenn man alles automatisch testen will, ist das sicher ein riesen Aufwand. Aber das ein Entwickler den Code den er ändert auch noch einmal testet ist eigentlich kein großer Aufwand, es würde einfach nur ein bisschen mehr Disziplin brauchen. Schon der Aufwand bis ein Tester das testet und findet und dann noch einen Bug einträgt, ist größer.

    Ich finde das eigentlich ganz normal, dass ich meinen Code teste. Meinen manche sie machen keine Fehler (ist ja offensichtlich nicht so) oder warum testet man sein Zeug nicht?



  • Einchecker schrieb:

    Es ist ganz offensichtlich, dass der der das eingecheckt hat, seinen Code nie ausprobiert hat.

    Sorry ich war faul 😃


Anmelden zum Antworten