Programowanie F # i testy jednostkowe?

Właśnie zacząłem z F #, który jest moim pierwszym językiem funkcjonalnym. Pracowałem prawie wyłącznie z językiem C # i bardzo się cieszę, jak F # prowadzi mnie do ponownego przemyślenia sposobu, w jaki piszę kod. Jeden aspekt, który uważam za nieco dezorientujący, to zmiana w procesie pisania kodu. Od lat używam TDD w C # i naprawdę doceniam, że mam testy jednostkowe, aby wiedzieć, gdzie jestem.

Do tej pory mój proces z F # polegał na pisaniu niektórych funkcji, bawieniu się nimi za pomocą konsoli interaktywnej, dopóki nie będę „w miarę” pewny, że działają, a także poprawianiu i łączeniu. Działa to dobrze w przypadku problemów na małą skalę, takich jak projekt Euler, ale nie wyobrażam sobie zbudowania w ten sposób czegoś dużego.

Jak ludzie podchodzą do testowania jednostkowego i tworzenia zestawu testów dla programu F #? Czy istnieje odpowiednik TDD? Wszelkie wskazówki lub myśli są mile widziane.

Programiści sterowani testami powinni czuć się jak w domu w językach funkcjonalnych, takich jak F #: małe funkcje, które dają deterministycznie powtarzalne wyniki, doskonale nadają się do testów jednostkowych. Istnieją również możliwości w języku F # ułatwiające pisanie testów. Weźmy na przykład wyrażenia obiektu . Możesz bardzo łatwo napisać podróbki dla funkcji, które jako dane wejściowe przyjmują typ interfejsu.

Jeśli już, F # jest pierwszorzędnym językiem obiektowym i możesz używać tych samych narzędzi i sztuczek, których używasz podczas wykonywania TDD w C #. Istnieją również narzędzia do testowania napisane w języku F # lub specjalnie dla niego:

• NaturalSpec
• FsCheck
• FsTest
• FsUnit

Matthew Podwysocki napisał świetną serię na temat testów jednostkowych w językach funkcjonalnych. Wujek Bob napisał również inspirującej artykuł tutaj .

Używam NUnit i nie wydaje mi się to tak trudne do odczytania ani uciążliwe w pisaniu:

open NUnit.Framework

[<TestFixture>]
type myFixture() = class

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

end

Ponieważ mój kod jest mieszanką języka F # i innych języków .Net, podoba mi się fakt, że testy jednostkowe piszę w zasadzie w ten sam sposób iz podobną składnią w językach F # i C #.

Spójrz na FsCheck , automatyczne narzędzie testujące dla F #, jest w zasadzie portem QuickCheck firmy Haskell. Pozwala na podanie specyfikacji programu w postaci właściwości, które powinny spełniać funkcje lub metody, a FsCheck sprawdza, czy właściwości te posiadają w dużej liczbie losowo generowanych przypadków.

Strona FsCheck CodePlex

Strona autora programu FsCheck

Jak sugeruje dglaubman, możesz użyć NUnit. xUnit.net zapewnia również wsparcie dla tego i dobrze współpracuje z TestDriven.net . Kod wygląda podobnie do testów NUnit, ale bez wymogu opakowywania testu w typ zawierający.

#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) 

Myślę, że to bardzo interesujące pytanie, nad którym sam bardzo się zastanawiałem. Moje myśli to tylko myśli, więc weź je za to, czym są.

Myślę, że sieć bezpieczeństwa zestawu testów automatycznych jest zbyt cennym atutem, aby go odpuścić, jakkolwiek pociągająca może być ta konsola interaktywna, więc planuję kontynuować pisanie testów jednostkowych, tak jak zawsze.

Jedną z głównych zalet platformy .NET są możliwości obsługi wielu języków. Wiem, że wkrótce będę pisać kod produkcyjny w języku F #, ale planuję napisać testy jednostkowe w języku C #, aby ułatwić sobie drogę do tego, co jest dla mnie nowym językiem. W ten sposób mogę również sprawdzić, czy to, co piszę w F #, będzie kompatybilne z C # (i innymi językami .NET).

Dzięki takiemu podejściu rozumiem, że istnieją pewne funkcje języka F #, których mogę używać tylko wewnętrznie w moim kodzie F #, ale nie mogę ich udostępniać w ramach mojego publicznego interfejsu API, ale zaakceptuję to, tak jak akceptuję dzisiaj, że są pewne rzeczy C # pozwala mi wyrazić (lubić uint), które nie są zgodne z CLS, więc powstrzymuję się od ich używania.

Możesz rzucić okiem na FSUnit - chociaż jeszcze go nie używałem, może warto spróbować. Z pewnością lepsze niż używanie na przykład (natywnego) NUnit w F #.

Mimo, że jestem trochę spóźniony na imprezę, chciałbym przywitać Mathiasa na F # (lepiej późno niż wcale;)) i dodać, że spodobałaby Ci się moja biblioteka testów jednostkowych Expecto

Expecto ma kilka funkcji, które mogą Ci się spodobać:

• Składnia F # w całym tekście, testy jako wartości; napisz zwykły F #, aby wygenerować testy
• Użyj wbudowanego modułu Expect lub biblioteki zewnętrznej, takiej jak Unquote, do potwierdzeń
• Testy równoległe domyślnie
• Przetestuj swój kod Hopac lub kod Async; Expecto jest asynchroniczne przez cały czas
• Podłączane rejestrowanie i metryki za pośrednictwem Logary Facade; łatwo pisz adaptery do systemów kompilacji lub korzystaj z mechanizmu czasowego do budowania pulpitu InfluxDB + Grafana z czasami wykonywania testów
• Wbudowana obsługa BenchmarkDotNet
• Wbuduj obsługę FsCheck; ułatwia tworzenie testów z wygenerowanymi / losowymi danymi lub budowanie niezmiennych modeli przestrzeni stanów obiektu / aktora

-

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/