Autofixture: Vorschlag: Folgen Sie für Tests dem Stil "Arrange Act Assert"

Tue es. Aber ich würde den Anfangsbuchstaben lieber groß schreiben, das heißt

// Arrange
// Act
// Assert

Anstatt von

// arrange
// act
// assert

Haben Sie triftige Gründe, den zweiten Fall zu bevorzugen?

Nein, Großbuchstaben sind für mich in Ordnung - es reicht, dass wir AAA verwenden :blush:

Sie können jede Phase auch durch eine Leerzeile trennen, dies ist die Formatierung, die ich heutzutage verwende. Dann kann der Testleser annehmen, dass es Gegeben/Wenn/Dann oder Arrangieren/Act/Assert oder sogar (der vierphasige geht hier) ist .

Mehr dazu lesen Sie im Abschnitt „Einfache Tests mit mehr als drei Zeilen Code“ hier .

Ich mag die Verwendung von Leerzeilen anstelle von Kommentaren in OSS nicht und stimme dieser Idee von Marks nicht zu. Siehe meinen Kommentar hier .

Kommentare zu jeder Testphase sind im Grunde Kommentare . Und in diesem speziellen Fall sind es Entschuldigungen , weil sie erklären, wie – statt warum .

Nun zurück zu AutoFixture, da alle Tests mit Kommentaren versehen sind und die Teardown- Phase der AAA ändern.

Und in diesem speziellen Fall sind es Entschuldigungen

Nun, ich beziehe mich auch oft auf diese Regel, aber in diesem speziellen Fall ziehe ich es vor, diese "Entschuldigungen" zu behalten 😄 Sie machen den Aufbau des Tests offensichtlicher und strenger. Ich persönlich finde es einfacher "beschriftete" Tests zu lesen, aber wahrscheinlich ist das einfach Gewohnheitssache 😉

aber wahrscheinlich ist das einfach gewohnheitssache

Dies; und vielleicht auch eine Frage, wer den Test eigentlich geschrieben hat.

Hallo, ich würde das gerne angehen. Ich bin ein großer Fan von Autofixture und verwende es ständig in meiner Arbeit und es wäre eine gute Möglichkeit, etwas zurückzugeben.
Im Grunde wollen Sie also in allen Testdateien Folgendes ändern:
// Fixture setup bis // Arrange
// Exercise System bis // Act
// Verify Outcome bis // Assert
und schließlich // Teardown zu nichts.

Ja, aber denken Sie daran, dass ein "Suchen und Ersetzen" möglicherweise nicht funktioniert, da einige Phasen in einigen Tests miteinander verbunden sind. Das heißt, Sie könnten auf das Übungssystem stoßen und das Ergebnis überprüfen und ähnliches, IIRC.

@moodmosaic Ich verstehe, ich plane, Datei für Datei kein vollständiges "Suchen und Ersetzen"

Dankeschön,
Eissa

@moodmosaic für // Exercise system and verify outcome sollte es ersetzt werden durch
// Act and Assert
Oder denkt ihr an etwas anderes?

Normalerweise verwende ich // Act & Assert da es prägnanter und cooler aussieht 😎 Sofern @moodmosaic keine

So oder so ist in Ordnung :halsbart:

Also versuche ich damit zu beginnen und nachdem ich die All.sln in VS 2017 zwei F#-Projekte geladen habe
( AutoFoq,AutoFoqUnitTest ) können nicht geöffnet werden. Ich habe null Erfahrung mit F#, daher wäre jede Hilfe dankbar

@micheleissa Stellen Sie sicher, dass Sie die neueste Version von VS (15.5.1 oder höher) verwenden, andernfalls wird das Projekt nicht geöffnet (MS hat Änderungen an ihrem F#-SDK vorgenommen). Stellen Sie außerdem sicher, dass git clean -fdx . in Root mit geschlossenem VS ausgeführt wird. Das heißt, die temporären Dateien zu bereinigen, falls Sie das Projekt zuvor ausgecheckt haben.

Beide Schritte sollten helfen. Lass es mich wissen, wenn sie es nicht getan haben

@zvirja Ich habe auf die neueste Version von VS 2017 15.5.2 aktualisiert und stehe immer noch vor dem gleichen Problem 😞

Hast du den zweiten Teil probiert?

• Schließen
• Kasse die neuesten master
• Gehen Sie zu root und führen Sie git clean -fdx .
• VS wieder öffnen?

Es scheint, dass Sie nur Reste vom vorherigen SDK haben.

Stellen Sie außerdem sicher, dass die F#-Tools auf Ihrem Computer installiert sind:

Ja, das zweite habe ich vergessen, sorry :)
Ich werde es jetzt versuchen

@zvirja das hat funktioniert, vielen Dank für die Hilfe!

Noch eine Frage, wie verbinde ich den Branch, an dem ich in meinem geforkten Repository arbeite, mit diesem Ticket?

Super, dass es funktioniert hat! 👍

Wie verbinde ich den Branch, an dem ich in meinem gegabelten Repository arbeite, mit diesem Ticket?

Ich würde vorschlagen, sich diesen Artikel anzusehen, der Workflow ist dort gut beschrieben: https://github.com/sevntu-checkstyle/sevntu.checkstyle/wiki/Development-workflow-with-Git :-Fork,-Branching,- Commits,-und-Pull-Anfrage

Grundsätzlich müssen Sie diesem Problem keinen Zweig zuordnen. Stattdessen erstellen Sie einen Pull-Request und erwähnen dieses Problem einfach im Hauptteil (siehe z. B. dieses ).

OK habe es. Dankeschön! Ich werde die Pull-Anfrage erstellen, während ich an dem Problem arbeite, damit Sie den Fortschritt überwachen und Feedback gemäß den Angaben in den Richtlinien für Beiträge geben können.