F # Entwicklung und Unit Testing?

Ich habe gerade mit F # angefangen, meiner ersten funktionalen Sprache. Ich habe quasi ausschließlich mit C # gearbeitet und genieße es sehr, wie F # mich dazu bringt, meine Schreibweise für Code zu überdenken. Ein Aspekt, den ich etwas desorientiert finde, ist die Änderung beim Schreiben von Code. Ich benutze TDD seit Jahren in C # und freue mich sehr über Unit-Tests, um zu wissen, wo ich mich befinde.

Bisher bestand mein Prozess mit F # darin, einige Funktionen zu schreiben, mit ihnen mit der interaktiven Konsole zu spielen, bis ich "ziemlich" sicher bin, dass sie funktionieren, und zu optimieren und zu kombinieren. Dies funktioniert gut bei kleinen Problemen wie dem Euler-Projekt, aber ich kann mir nicht vorstellen, auf diese Weise etwas Großes zu bauen.

Wie gehen Menschen mit Unit-Tests um und erstellen eine Testsuite für ein F # -Programm? Gibt es ein Äquivalent zu TDD? Hinweise oder Gedanken sind willkommen.

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 Unit-Tests. Es gibt auch Funktionen in der F # -Sprache, die das Schreiben von Tests erleichtern. Nehmen Sie zum Beispiel Objektausdrücke . Sie können sehr einfach Fälschungen für Funktionen schreiben, deren Eingabe ein Schnittstellentyp ist.

Wenn überhaupt, ist F # eine erstklassige objektorientierte Sprache, und Sie können dieselben Tools und Tricks verwenden, die Sie beim Ausführen von TDD in C # verwenden. Es gibt auch einige Testtools, die in oder speziell für F # geschrieben wurden:

• NaturalSpec
• FsCheck
• FsTest
• FsUnit

Matthew Podwysocki hat eine großartige Serie über Unit-Tests in funktionalen Sprachen geschrieben. Uncle Bob schrieb auch einen Gedanken Artikel zu provozieren hier .

Ich benutze NUnit und es fällt mir nicht so schwer zu lesen oder schwer zu schreiben:

open NUnit.Framework

[<TestFixture>]
type myFixture() = class

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

end

Da mein Code eine Mischung aus F # und anderen .Net-Sprachen ist, gefällt mir die Tatsache, dass ich die Unit-Tests im Grunde auf die gleiche Weise und mit ähnlicher Syntax sowohl in F # als auch in C # schreibe.

Werfen Sie einen Blick auf FsCheck , ein automatisches Testwerkzeug für F #, ist im Grunde eine Portierung von Haskells QuickCheck. Sie können eine Spezifikation des Programms in Form von Eigenschaften bereitstellen, die die Funktionen oder Methoden erfüllen sollten, und FsCheck testet, ob die Eigenschaften in einer großen Anzahl zufällig generierter Fälle enthalten sind.

FsCheck CodePlex Page

FsCheck Author Page

Wie dglaubman vorschlägt, können Sie NUnit verwenden. xUnit.net bietet auch Unterstützung dafür und funktioniert gut mit TestDriven.net . Der Code ähnelt NUnit-Tests, ohne dass der Test in einen enthaltenen Typ eingeschlossen 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) 

Ich denke, das ist eine sehr interessante Frage, über die ich mich selbst viel gewundert habe. Meine Gedanken sind bisher nur Gedanken, also nimm sie als das, was sie sind.

Ich denke, dass das Sicherheitsnetz einer automatisierten Testsuite zu wertvoll ist, um loszulassen, so verlockend diese interaktive Konsole auch sein mag, daher plane ich, weiterhin Unit-Tests zu schreiben, wie ich es immer getan habe.

Eine der Hauptstärken von .NET sind die sprachübergreifenden Funktionen. Ich weiß, dass ich bald F # -Produktionscode schreiben werde, aber mein Plan ist es, Unit-Tests in C # zu schreiben, um mir den Weg in eine für mich neue Sprache zu erleichtern. Auf diese Weise kann ich auch testen, ob 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 verfügbar mache, aber ich werde das akzeptieren, genauso wie ich heute akzeptiere, dass es bestimmte Dinge gibt Mit C # kann ich ausdrücken (wie uint), die nicht CLS-kompatibel sind, und daher verzichte ich darauf, sie zu verwenden.

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.

Obwohl ich ein bisschen zu spät zur Party komme, würde ich Mathias gerne in F # begrüßen (besser spät als nie;)) und mich darauf einlassen, dass Ihnen Expecto gefallen könnte

Expecto bietet einige Funktionen, die Ihnen gefallen könnten:

• F # -Syntax durchgehend, Tests als Werte; Schreiben Sie einfach F #, um Tests zu generieren
• Verwenden Sie das integrierte Expect-Modul oder eine externe Bibliothek wie Unquote für Zusicherungen
• Standardmäßig parallele Tests
• Testen Sie Ihren Hopac-Code oder Ihren Async-Code. Expecto ist durchweg asynchron
• Steckbare Protokollierung und Metriken über Logary Facade; Schreiben Sie einfach Adapter für Build-Systeme oder verwenden Sie den Timing-Mechanismus zum Erstellen eines InfluxDB + Grafana-Dashboards für die Ausführungszeiten Ihrer Tests
• Integrierte Unterstützung für BenchmarkDotNet
• Integrierte Unterstützung für FsCheck; macht es einfach, Tests mit generierten / zufälligen Daten zu erstellen oder invariante Modelle des Zustandsraums Ihres Objekts / Akteurs zu erstellen

- -

open Expecto

let tests =
  test "A simple test" {
    let subject = "Hello World"
    Expect.equal subject "Hello World" "The strings should equal"
  }

[<EntryPoint>]
let main args =
  runTestsWithArgs defaultConfig args tests

https://github.com/haf/expecto/