Essen, schlafen und atmen Unit Testing / TDD / BDD [geschlossen]

StackOverflow https://stackoverflow.com/questions/1616090

Frage

I Unit-Tests zu tun schreiben, während APIs und Kernfunktionalitäten zu schreiben. Aber ich will das kühle fanboy sein, der isst, schläft und atmet TDD und BDD. Was ist der beste Weg, um die richtige Art und Weise mit TDD / BDD, um loszulegen? Alle Bücher, Ressourcen, Frameworks, Best Practices?

Meine Umgebung ist Java-Backend mit Grails-Frontend integriert mit mehreren externen Web-Services und Datenbanken.

War es hilfreich?

Lösung

Ein guter Anfang Blogs liest. Dann kaufen die Bücher der Menschen, die bloggen. Einige Ich würde empfehlen:

"Uncle Bob" Martin und die Jungs von Object Mentor: http://blog.objectmentor.com/

P. S. erhalten Bobs Buch Clean Code:

http://www.amazon.com/Clean-Code-Handbook-Software- Handwerk / dp / 0132350882

Mein Freund Tim Ottinger (ehemalige Object Mentor Geck) http://agileinaflash.blogspot.com/ http://agileotter.blogspot.com/

Die Jetbrains Jungs: http://www.jbrains.ca/permalink/285

hatte ich das Bedürfnis dazu zu erweitern, wie alle anderen, nur scheint Ihnen ihre Meinung TDD geben wollen und nicht Sie auf Ihrer Suche helfen ein Jedi-Ninja zu werden. Der Michael Jordan von TDD ist Kent Beck. Er hat wirklich das Buch schreibe darauf:

http://www.amazon.com/Test-Driven-Development-Kent- Beck / dp / 0321146530

er bloggt auch:

http://www.threeriversinstitute.org/blog/?p=29

anderer "berühmter" Unterstützer von TDD enthalten:

Alle sind großartige Menschen zu folgen. Sie sollen auch einige Konferenzen wie Agile 2010 oder Software Craftsmanship Teilnahme an (dieses Jahr sind sie in der gleichen Zeit in Chicago gehalten wurden)

Andere Tipps

Ich mag es nicht, wenn die Leute sagen, „Praxis X nie schlecht;., Wenn es nicht funktioniert, Sie tun es nicht richtig“ Sorry, es hat das gleiche Gefühl wie bei jedem anderen übereifrigen religiösen Dogma. Ich kaufe es nicht.

ich mit diesen Leuten zustimmen, die sagen, dass die beste Lösung, um Ihre Zeit und Geld leisten können, sollte das Ziel sein.

Jeder, der TDD-Objekte sollten nicht automatisch von Vernachlässigung Qualität vorgeworfen werden. ( „Also, wenn tat stoppen Sie Ihre Frau zu schlagen?“) Tatsache ist, dass Software-Fehler in ihm hat, und die Kosten für alle von ihnen zu beseitigen hat gegen den Nutzen abgewogen werden.

Das gleiche gilt bei der Herstellung. Maßtoleranzen und Oberflächen auf Oberflächen sind nicht alle gleich, weil manchmal eine enge Toleranz und eine spiegelnde Oberfläche sind nicht gerechtfertigt.

Ja, ich schreibe Unit-Tests, wenn auch nicht oft, bevor ich die Klasse schreiben. Ich habe die Wirkung von Tests auf dem Design zu sehen. Ich messe und Code-Coverage beobachten. Wenn ich, dass meine Berichterstattung finden nicht akzeptabel ist, schreibe ich mehr Tests. Ich verstehe den Vorteil eines Sicherheitsnetzes von Unit-Tests für Refactoring. Ich verfolge diese Praktiken auch wenn ich arbeite allein, weil ich die Vorteile erlebt habe aus erster Hand. Ich verstehe schon.

Aber ich würde auf jeden Mitspieler einen skeptischen Blick, die über nervt mich begonnen „Essen, Schlafen und Atmen Unit-Tests und TDD.“

  

Mein Manager sagt, dass der einzige Weg, die mir eine Förderung erhalten, wenn ich das Team zu TDD / BDD bekommen kann.

Denken Sie überhaupt, dass vielleicht das macht man sich wie ein saugen-up klingen? Haben Sie festgestellt, dass Ihr Gezeter den Rest Ihres Teams entfremdet hat?

Diese Antwort könnte mir ein paar Ruf Punkte verlieren, aber es musste gesagt werden.

Ich denke, ein besserer Ansatz wäre es, sich zu üben und lassen Sie andere den Nutzen sehen. Mit gutem Beispiel vorangehen. Es wird weit überzeugender sein, als den Mund läuft.

Meine Güte, Grails hat Test Generation eingebaut. Wenn Sie in einem Team arbeiten, die Grails verwendet, wie viel mehr Verkauf benötigt wird?

Aus der Praxis IMHO: Tun Sie, was praktisch ist, und nicht nur, weil es ein Prozess ist. Vergessen Sie nicht, was das Ziel der Schreiben von Anwendungen ist, und in der Geschäftswelt ist es nicht Schreiben von Tests. mich nicht falsch, sie haben ihren Platz, aber das sollte nicht das Ziel sein.

Finden Sie jemanden, der TDD / BDD und pair-Programm mit ihnen getan hat.

Metrics sind, IMHO, ist der beste Weg von hier nach dort zu bekommen. Verfolgen Sie, wie gut Sie den Code abgedeckt ist, halten Deltas von Codekomplexität für jede verpflichten, Use-Test-Läufer, die den Code für Änderungen beobachten und ständig die entsprechenden Tests erneut ausführen. Lassen Sie niemals Testlängen über ein paar Zeilen zu erhalten, so dass alle Ihre Werkzeuge gut funktionieren. Und ich würde einmal im Monat empfohlen, einen Tag frei nehmen Sie den Code durch eine Mutation Tester zu laufen. An diesem Tag sollte nur auf das Schreiben von Tests gewidmet sein. All diese Dinge werden Sie Schmerzen bringen, wenn Sie gute TDD nicht bereits tun. Lernen Sie von dem Schmerz, und in kürzester Zeit überhaupt, werden Sie es richtig zu machen.

Und nie aus den Augen verlieren, was die Tests für: gewünschtes Verhalten zu beschreiben. Sie sind Ihre ausführbare Spezifikation. (Dies ist auch, warum ich Gurke ;! Jetzt können Sie Ihre PHB, um Ihre Tests für Sie schreiben Nun, vielleicht nicht ganz so gut, aber es ist nah!)

„PS:. Mein Manager sagt, dass der einzige Weg, die mir eine Förderung erhalten, wenn ich das Team zu TDD / BDD bekommen kann“

Der einzige realistische Weg, um ein Team zu bekommen, etwas zu tun (ohne dass Sie in dem Prozess zu töten) ist ihnen klar zu zeigen, dass es ihnen zugute kommen wird, ihre Gewohnheiten zu ändern. Mit anderen Worten, Code schreiben. Viele Code. Tonnen von Code. Und dann, wenn die entscheidende E-Mail, dass die Abspaltungen der Spezifikation radikal ankommen, ihnen zeigen, dass Sie Ihren Code leicht mit Refactoring ändern kann und was ist schlimmer, weil Sie waren vorbereitet für Sie es mit Ihren Tests an Ort und Stelle. Die Bar war grün, Hack Hack Hack, RED BAR !!!!, Hack Hack Hack, grüne Balken, nach Hause gehen.

Lesen Sie Kent Becks Buch über Test Driven Design. Beginnen Sie mit Tests und führen Sie dann den Code. Erhalten Sie einen Build-Server ausgeführt wird, die die Tests laufen lässt! Sie haben nicht brauchen ot es für das ganze Team -. Tun es für sich selbst und ihnen zeigen, dass es hilft,

Predigen nur ärgert Eingeborenen:)

Ich habe seit ein paar Jahren TDD zu tun, aber in letzter Zeit habe ich begann, mich mehr in die BDD Art und Weise mein Design und Entwicklung des Fahrens. Ressourcen, die mir geholfen loszulegen auf BDD erste war und Formost Dan North Blog (der ‚Gründer‘ von BDD). Schauen Sie sich auf BDD Einführung. Es gibt auch eine ‚offizielle‘ BDD Wiki über behaviour-driven.org mit einigem guten Beitrag lesenswert.

Das einzige, was ich wirklich schwer zu finden, wenn sie mit BDD ausgehend ist (und immer noch ein bisschen schwer zu finden), wie diese Szenarien zu formulieren, um sie geeignet zu BDD zu machen. Scott Bellware ist ein Mann gut Mann BDD (oder Kontext Spesification wie er es gerne Münze) und sein Artikel Verhalten-Driven Development in dem Code Magazin hat mir geholfen, die BDD Denkweise viel auf dem Verständnis und User Stories zu formulieren.

Ich würde empfehlen, auch das TekPub Screen Verhalten Driven Design mit Specflow von Rob Conery. Ein großes Intro zu BDD und zu einem Werkzeug (SpecFlow) sehr gut geeignet für die BDD in C # zu tun.

Wie für TDD-Ressourcen gibt es bereits viele gute Empfehlungen hier. Aber ich will nur ein paar Bücher hinweisen, die kann ich wirklich empfehlen;

Für den Start Unit-Tests zu tun, dann lesen, wie es richtig letzte Ihrem Team beibringen, wie und an TDD erhält an Bord -. Weil in meiner Erfahrung nichts wichtiger ist dann zu tun Unit-Tests mit dem ganzen Team

Sie werden auch brauchen einen richtigen Build-Prozess -. Einen Build-Server, die Ihren Code bauen würde, und führen Sie Ihre testst Ich empfehle, mit Teamcity (kostenlos mit Einschränkungen)

Lernen, wie man eine gute Unit-Tests nach rechts ist der schwierige Teil - einige davon können Sie selbst lernen werden (solange Sie Unit-Tests zu halten) und der Rest können Sie von der Suche im Internet lernen

.

Sie wissen, dass Sie Ihr Ziel erreicht haben, wenn das Gerät nicht das Schreiben von Tests im Rahmen der Entwicklungs Dir nur falsch aussehen wird.

Denken Sie daran, agil bedeutet, dass Sie nicht ganz auf ein bestimmtes Verfahren ausverkauft. Wenn Sie auf etwas arbeiten, wo die Vorteile von TDD sind es nicht wert (wie tut Trial-and-Error-Änderungen auf einer Schaukel-Schnittstelle), dann nicht TDD verwenden.

Ich kann nicht sehen, dass jemand wirklich zum Ausdruck gebracht hat, dass TDD ist nicht über das Testen. TDD-ing ist über das erwartete Verhalten zum Ausdruck, bevor die kleine Verhaltensverändernde Modifikation zu tun. Dies verbessert Design und ermöglicht in einer Art und Weise konzentriert habe ich noch nie erlebt. Sie erhalten Tests, die Ihre Zukunft Refactorings und 90% Deckung kostenlos schützen.

Um es zu lernen, würde ich vorschlagen, (zusammenfassend, was andere gesagt haben, und das Hinzufügen von einem meiner eigenen):

  1. die Blogs besuchen und die Bücher lesen oben erwähnten
  2. paaren mit bewandert in TDD
  3. Praxis

übte ich das Bowling kata (Übung) auf meiner eigenen etwa 20-mal (ca. 30 Minuten pro Stück), bevor ich das Licht zu sehen begann. Begann von Onkel Bobs Beschreibung davon Analyse hier . Es gibt eine Vielzahl von Katas auf der codingdojo.org Website einschließlich Lösungen und Diskussionen. Probieren Sie es!

Um ein Angebot von Nike zu nehmen. Just do it

Zweiter Ratschlag - verlassen nie auf jemand anderes Interface. Schreiben Sie immer auf der Ebene der einzelnen Klassen, auf die Schnittstelle, die Sie bestanden wünschte -. Aufzuschreiben einen Adapter an der tatsächlichen Durchführung als notwendig

Auch finde ich es sinnvoll, Rückgabewerte auf Methoden zu vermeiden, und des Codes in Bezug auf die Message-Passing zu denken, anstatt Funktionsaufrufe.

YMMV.

Vor einem Jahr hatte ich wenig Ahnung, wie TDD zu tun (aber wirklich wollte (wie frustrierend)) und hatte noch nie von BDD gehört ... jetzt habe ich beide zwanghaft. Ich habe in einer .NET-Entwicklungsumgebung, und zwar nicht Java, aber ich ersetzt sogar die „F5 - Run“ Taste mit einem Makro entweder laufen Gurke (BDD) oder MBUnit (TDD) je nachdem, ob es sich um ein Merkmal / Szenario oder Spezifikation ist. Kein Debugger, wenn überhaupt möglich. $ 1 in der jar, wenn Sie den Debugger (JOKING (Art)) verwendet werden.

Der Prozess ist sehr genial. Der Rahmen, den wir verwenden, sind zusätzlich wird durch die Oracle Ich habe über kommen gesegnet worden, und Aufnahme von Informationen aus, und dieser Rahmen er / wir verwenden, ist MavenThought.

Alles beginnt mit BDD. Unsere BDD ist gerade nach oben Gurke ontop von Eisen Rubin.

Feature:

Szenario: ....    I do blah ...
   Wenn ich etwas anderes tun ...    Dann wunderbare Dinge geschehen ...

Szenario: ...

Und das ist nicht Unit-Tests selbst, sondern es treibt die Funktion Szenario Szenario, und wiederum die Einheit (Test) Spezifikationen .. So können Sie auf einem Szenario zu starten, und mit jedem Schritt müssen Sie in dem Szenario vervollständigen es treibt Ihr TDD.

Und das TDD wir verwendet haben ist eine Art von BDD in einer Art und Weise, weil wir an das Verhalten sehen das SUT (System Under Test) erfordert und ein Verhalten gemäß Spezifikation (Klasse „test“ Datei) angegeben.

Beispiel:

Hier ist die Spezifikation für ein Verhalten: Wenn das System Under Test erstellt wird,

.

Es gibt eine weitere Spezifikation (C # When_blah_happens Klasse-Datei) für ein anderes Verhalten, wenn eine Eigenschaft ändert, aber das ist in eine separate Datei getrennt werden. 

using MavenThought.Commons.Testing;
using SharpTestsEx;

namespace Price.Displacement.Module.Designer.Tests.Model.Observers
{
    /// <summary>
    /// Specification when diffuser observer is created
    /// </summary>
    [ConstructorSpecification]
    public class When_diffuser_observer_is_created
        : DiffuserObserverSpecification
    {
        /// <summary>
        /// Checks the diffuser injection
        /// </summary>
        [It]
        public void Should_return_the_injected_diffuser()
        {
            Sut.Diffuser.Should().Be.SameInstanceAs(this.ConcreteDiffuser);
        }
    }
}

Dies ist wahrscheinlich das einfachste Verhalten für ein SUT, weil in diesem Fall, wenn es erstellt wird, sollte der Diffusor Eigenschaft der gleiche wie der injizierten Diffusor sein. Ich hatte einen Beton Diffusor statt einem Mock zu verwenden, da in diesem Fall der Diffusor ist ein Kern / Domain-Objekt und hat keine Eigenschaft Benachrichtigung für die Schnittstelle. 95% der Zeit, die wir für alle unsere Abhängigkeiten wie Dep beziehen (), statt die reale Sache der Injektion.

Oft haben wir mehr als ein [It] Should_do_xyz (), und manchmal auch ein gutes Stück von Setup wie vielleicht bis zu 10 Zeilen Anstoßen. Dies ist nur ein sehr einfaches Beispiel ohne GivenThat () oder AndGivenThatAfterCreated () in dieser Spezifikation.

Für die Einrichtung von jeder Spezifikation im Allgemeinen wir immer nur ein paar Methoden der Spezifikation außer Kraft setzen müssen:

GivenThat () ==> dies geschieht, bevor der SUT erstellt wird.

CreatSut () ==> Wir auto Mock Schaffung des SUT mit StructureMap und 90% der Zeit brauchen, nie außer Kraft zu setzen, aber wenn Sie Konstruktor sind eine Beton Injektion, müssen Sie dies außer Kraft zu setzen.

AndGivenThatAfterCreated () => dies geschieht nach dem SUT erstellt wird.

WhenIRun () => es sei denn, es wird [ConstructorSpecification] Wir verwenden diese eine Zeile Code ausgeführt werden, dass das Verhalten ist, dass wir für das SUT sind folgende Einzelheiten

Auch wenn es gemeinsame Verhalten von zwei oder mehreren Spezifikationen des gleichen SUT, bewegen wir uns, dass in den Grund specifcation.

Alles, was ich tun muss, um die Spezifikation ausgeführt ist hervorzuheben seinen Namen, zB „When_diffuser_observer_is_created“ und drücken Sie F5, denn denken Sie daran, für mich läuft F5 einen Rake-Aufgabe entweder Test: feature [Tag], wenn Gurke oder Test: class [SUT ]. Das macht Sinn für mich, weil jedes Mal wenn Sie den Debugger ausführen es einen Wurf entfernt ist, wird kein Code erstellt (oh, und es kostet ein von $ 1 (Scherz)).

Dies ist eine sehr, sehr saubere Art und Weise Verhalten mit TDD zu spezifizieren und mit wirklich, wirklich einfach SUTs und einfachen Spezifikationen. Wenn Sie versuchen, und Cowboy-Coder und die SUT crappy mit harten Abhängigkeiten schreiben, etc, werden Sie den Schmerz fühlen, versuchen, TDD zu tun und bekommen satt / aufgeben oder den sauren Apfel beißen und tut es richtig.

Und hier ist die eigentliche SUT. Wir haben ein wenig Phantasie und verwenden Postsharp Eigenschaft hinzufügen informieren auf dem Diffusor geändert, so damit die Post.Cast <>. Und wieder that ist, warum ich ein Beton statt Mock injiziert. Wie auch immer, wie können Sie das fehlende Verhalten in einer anderen Spezifikation definiert sehen, wenn alles auf dem Diffusor ändert. 

using System.ComponentModel;
using MavenThought.Commons.Events;
using PostSharp;
using Price.Displacement.Core.Products;
using Price.Displacement.Domain;

namespace Price.Displacement.Desktop.Module.Designer.Model.Observers
{
    /// <summary>
    /// Implementation of current observer for the selected product
    /// </summary>
    public class DiffuserObserver : AbstractNotifyPropertyChanged, IDiffuserObserver
    {
        /// <summary>
        /// gets the diffuser
        /// </summary>
        public IDiffuser Diffuser { get; private set; }

        /// <summary>
        /// Initialize with a diffuser
        /// </summary>
        /// <param name="diffuser">The diffuser to observe</param>
        public void Initialize(IDiffuser diffuser)
        {
            this.Diffuser = diffuser;
            this.NotifyInterface().PropertyChanged += (x, e) => this.OnPropertyChanged(e.PropertyName);
        }

        /// <summary>
        /// Gets the notify interface to use
        /// </summary>
        /// <returns>The instance of notify property changed interface</returns>
        protected INotifyPropertyChanged NotifyInterface()
        {
            return Post.Cast<Diffuser, INotifyPropertyChanged>((Diffuser)Diffuser);
        }
    }
}

Abschließend diese BDD / TDD-Stil Entwicklung Felsen. Es dauerte ein Jahr, aber ich bin ein total convert als Weg des Lebens. Ich hätte das nicht gelernt, sich auf eigene Faust. Ich nahm alles von Oracle http://orthocoders.com/ .

rote oder blaue Pille, die Wahl liegt bei Sie.

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top