F # Entwicklung und Komponententests?

Question

Ich habe gerade mit F # angefangen, was meine erste funktionale Sprache ist. Ich habe fast ausschließlich mit C# gearbeitet und genieße es sehr, wie F # mich dazu bringt, zu überdenken, wie ich Code schreibe. Ein Aspekt, den ich etwas verwirrend finde, ist die Veränderung des Code-Schreibens. Ich benutze TDD seit Jahren in C# und schätze es wirklich, Unit-Tests zu haben, um zu wissen, wo ich bin.

Bisher war mein Prozess mit F #, einige Funktionen zu schreiben, mit ihnen mit der interaktiven Konsole zu spielen, bis ich "einigermaßen" sicher bin, dass sie arbeiten, und zwicken & kombinieren. Das funktioniert gut bei kleinen Problemen wie dem Euler-Projekt, aber ich kann mir nicht vorstellen, so etwas Großes zu bauen.

Wie nähern sich Personen dem Testen von Einheiten und erstellen eine Testsuite für ein F # -Programm? Gibt es ein Äquivalent zu TDD? Alle Hinweise oder Gedanken sind willkommen.

Answer 1

Testgetriebene Entwickler sollten sich in funktionalen Sprachen wie F # wie zu Hause fühlen: kleine Funktionen, die deterministisch wiederholbare Ergebnisse liefern, eignen sich perfekt für Komponententests. Es gibt auch Fähigkeiten in der Sprache F #, die das Schreiben von Tests erleichtern. Nehmen wir zum Beispiel Object Expressions. Sie können sehr einfach Fälschungen für Funktionen schreiben, die als Eingabe einen Schnittstellentyp verwenden.

Wenn überhaupt, ist F # eine objektorientierte Sprache erster Klasse, und Sie können die gleichen Werkzeuge und Tricks verwenden, die Sie beim Ausführen von TDD in C# verwenden. Es gibt auch einige Tests-Tools geschrieben in oder speziell für F #:

• NaturalSpec
• FsCheck
• FsTest
• FsUnit

Matthew Podwysocki ein großes series auf Unit-Tests in funktionalen Sprachen geschrieben . Onkel Bob schrieb auch einen zum Nachdenken anregenden Artikel here.

Answer 2

Sie könnten einen Blick auf FSUnit werfen - obwohl ich es noch nicht benutzt habe, könnte es einen Versuch wert sein. Sicher besser als zum Beispiel (native) NUnit in F # zu verwenden.

Answer 3

Ich denke, das ist eine sehr interessante Frage, über die ich mich selbst oft gefragt habe. Meine Gedanken sind bisher nur Gedanken, also nimm sie für das, was sie sind.

Ich denke, dass das Sicherheitsnetz einer automatisierten Testsuite zu wertvoll ist, um loslassen zu können, egal wie verlockend die interaktive Konsole auch sein mag, also plane ich wie immer Unit Tests zu schreiben.

Eine der größten Stärken von .NET sind die sprachübergreifenden Funktionen. Ich weiß, dass ich bald F # -Produktionscode schreiben werde, aber mein Plan ist, Komponententests in C# zu schreiben, um mir den Weg zu einer neuen Sprache zu ebnen. Auf diese Weise kann ich auch testen, dass das, was ich in F # schreibe, mit C# (und anderen .NET-Sprachen) kompatibel ist.

Mit diesem Ansatz verstehe ich, dass es bestimmte Funktionen von F # gibt, die ich nur intern in meinem F # -Code verwenden kann, aber nicht als Teil meiner öffentlichen API aussetzen, aber ich werde das akzeptieren, genauso wie ich das heute akzeptiere Es gibt bestimmte Dinge, die C# mir erlaubt, (wie uint) auszudrücken, die nicht CLS-konform sind, und daher verzichte ich darauf, sie zu verwenden.

Answer 4

Werfen Sie einen Blick auf FsCheck, ein automatisches Test-Tool für F #, ist im Grunde ein Port von Haskell's QuickCheck. Es ermöglicht Ihnen, eine Spezifikation von das Programm, in Form von Eigenschaften, die die Funktionen oder Methoden sollten erfüllen, und FsCheck Tests, die die Eigenschaften in einer großen Anzahl von zufällig generierten Fällen halten.

FsCheck CodePlex Page

FsCheck Author Page

Answer 5

Ich verwende NUnit, und es gefällt mir nicht so hart treffen zu lesen oder zu beschwerlich schreiben:

open NUnit.Framework 

[<TestFixture>] 
type myFixture() = class 

    [<Test>] 
    member self.myTest() = 
     //test code 

end 

Seit meinem Code eine Mischung aus F # und andere .Net-Sprachen, ich mag die Tatsache, dass ich die Unit-Tests im Grunde die gleiche Art und Weise und mit ähnlicher Syntax in F # und C# schreiben.

Answer 6

Wie dglasman empfiehlt, können Sie NUnit verwenden. xUnit.net bietet auch Unterstützung dafür und funktioniert gut mit TestDriven.net. Der Code ähnelt NUnit-Tests, jedoch ohne dass der Test in einen Containertyp eingebettet werden muss.

#light 

// Supply a module name here not a combination of module and namespace, otherwise 
// F# cannot resolve individual tests nfrom the UI. 
module NBody.DomainModel.FSharp.Tests 

open System 
open Xunit 

open Internal 

[<Fact>] 
let CreateOctantBoundaryReordersMinMax() = 
    let Max = VectorFloat(1.0, 1.0, 1.0) 
    let Min = VectorFloat(-1.0, -1.0, -1.0) 

    let result = OctantBoundary.create Min Max 

    Assert.Equal(Min, result.Min)  
    Assert.Equal(Max, result.Max)