Sviluppo F # e unit test?

Ho appena iniziato con F #, che è il mio primo linguaggio funzionale. Ho lavorato quasi esclusivamente con C # e mi piace molto il modo in cui F # mi porta a ripensare a come scrivo il codice. Un aspetto che trovo un po 'disorientante è il cambiamento nel processo di scrittura del codice. Uso TDD da anni in C # e apprezzo molto i test unitari per sapere dove mi trovo.

Finora, il mio processo con F # è stato quello di scrivere alcune funzioni, giocarci con la console interattiva fino a quando non sono "ragionevolmente" sicuro che funzionino, e modificare e combinare. Funziona bene su problemi su piccola scala come il Progetto Eulero, ma non riesco a immaginare di costruire qualcosa di grande in questo modo.

In che modo le persone affrontano i test di unità e creano una suite di test per un programma F #? Esiste un equivalente a TDD? Eventuali suggerimenti o pensieri sono apprezzati.

Gli sviluppatori basati sui test dovrebbero sentirsi a casa in linguaggi funzionali come F #: piccole funzioni che forniscono risultati ripetibili in modo deterministico si prestano perfettamente agli unit test. Esistono anche funzionalità nel linguaggio F # che facilitano la scrittura di test. Prendi, ad esempio, Object Expressions . Puoi scrivere facilmente falsi per funzioni che prendono come input un tipo di interfaccia.

Se non altro, F # è un linguaggio orientato agli oggetti di prima classe e puoi usare gli stessi strumenti e trucchi che usi quando esegui TDD in C #. Sono disponibili anche alcuni strumenti di test scritti o specificatamente per F #:

• NaturalSpec
• FsCheck
• FsTest
• FsUnit

Matthew Podwysocki ha scritto una serie fantastica sui test di unità nei linguaggi funzionali. Anche lo zio Bob ha scritto un articolo stimolante qui .

Uso NUnit e non mi sembra difficile da leggere o oneroso da scrivere:

open NUnit.Framework

[<TestFixture>]
type myFixture() = class

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

end

Poiché il mio codice è un mix di F # e altri linguaggi .Net, mi piace il fatto che scrivo gli unit test sostanzialmente nello stesso modo e con sintassi simile sia in F # che in C #.

Dai un'occhiata a FsCheck , uno strumento di test automatico per F #, che è fondamentalmente un port di QuickCheck di Haskell. Consente di fornire una specifica del programma, sotto forma di proprietà che le funzioni oi metodi dovrebbero soddisfare, e FsCheck verifica che le proprietà contengano in un gran numero di casi generati casualmente.

FsCheck CodePlex Page

Pagina dell'autore di FsCheck

Come suggerisce dglaubman, puoi usare NUnit. xUnit.net fornisce anche il supporto per questo e funziona bene con TestDriven.net . Il codice è simile ai test NUnit ma senza la necessità di racchiudere il test in un tipo contenitore.

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

Penso che questa sia una domanda molto interessante su cui mi sono chiesto molto io stesso. I miei pensieri finora sono solo pensieri, quindi prendili per quello che sono.

Penso che la rete di sicurezza di una suite di test automatizzata sia una risorsa troppo preziosa per lasciarla andare, per quanto allettante possa essere quella console interattiva, quindi ho intenzione di continuare a scrivere test unitari come ho sempre fatto.

Uno dei principali punti di forza di .NET sono le capacità cross-language. So che presto scriverò il codice di produzione F #, ma il mio piano è scrivere unit test in C # per facilitare il mio passaggio a quello che per me è un nuovo linguaggio. In questo modo, posso anche verificare che ciò che scrivo in F # sarà compatibile con C # (e altri linguaggi .NET).

Con questo approccio, capisco che ci sono alcune funzionalità di F # che posso usare solo internamente nel mio codice F #, ma non esporre come parte della mia API pubblica, ma lo accetterò, così come accetto oggi che ci sono certe cose C # mi consente di esprimere (mi piace uint) che non sono conformi a CLS, quindi mi astengo dall'usarli.

Potresti dare un'occhiata a FSUnit , anche se non l'ho ancora usato, potrebbe valere la pena provare. Sicuramente migliore rispetto all'utilizzo ad esempio (nativo) di NUnit in F #.

Nonostante sia un po 'in ritardo alla festa, vorrei dare il benvenuto a Mathias in F # (meglio tardi che mai;)) e farmi notare che potrebbe piacerti la mia libreria di unit test, Expecto

Expecto ha alcune funzionalità che potrebbero piacerti:

• Sintassi F # in tutto, test come valori; scrivi in ​​F # semplice per generare test
• Usa il modulo Expect integrato o una libreria esterna come Unquote per le asserzioni
• Test paralleli per impostazione predefinita
• Prova il tuo codice Hopac o il tuo codice Async; Expecto è asincrono dappertutto
• Registrazione e metriche collegabili tramite Logary Facade; scrivere facilmente adattatori per sistemi di compilazione o utilizzare il meccanismo di temporizzazione per creare un dashboard InfluxDB + Grafana dei tempi di esecuzione dei test
• Supporto integrato per BenchmarkDotNet
• Build in supporto per FsCheck; semplifica la creazione di test con dati generati / casuali o la creazione di modelli invarianti dello spazio degli stati dell'oggetto / attore

-

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/