Développement F # et tests unitaires?

Question

Je viens de commencer avec F #, qui est mon premier langage fonctionnel. J'ai travaillé presque exclusivement avec C#, et j'aime beaucoup comment F # m'amène à repenser la façon dont j'écris le code. Un aspect que je trouve un peu désorientant est le changement dans le processus d'écriture du code. J'utilise TDD depuis des années en C# et j'apprécie vraiment d'avoir des tests unitaires pour savoir où je suis. Jusqu'ici, mon processus avec F # a été d'écrire certaines fonctions, de jouer avec eux avec la console interactive jusqu'à ce que je sois "raisonnablement" sûr qu'ils fonctionnent, et de modifier & combiner. Cela fonctionne bien sur des problèmes à petite échelle comme le projet Euler, mais je ne peux pas imaginer construire quelque chose de cette façon.

Comment les gens abordent-ils les tests unitaires et la construction d'une suite de tests pour un programme F #? Y a-t-il un équivalent à TDD? Tout pointeur ou pensée est apprécié.

Answer 1

Les développeurs pilotés par les tests devraient se sentir comme chez eux dans les langages fonctionnels comme F #: les petites fonctions qui donnent des résultats déterministes et reproductibles se prêtent parfaitement aux tests unitaires. Il y a aussi des capacités dans le langage F # qui facilitent les tests d'écriture. Prenez, par exemple, Object Expressions. Vous pouvez très facilement écrire des faux pour des fonctions qui prennent comme entrée un type d'interface. Si quelque chose, F # est un langage orienté objet de première classe et vous pouvez utiliser les mêmes outils et astuces que vous utilisez lorsque vous faites TDD en C#. Il y a aussi quelques outils de tests écrits ou spécifiquement pour F #:

• NaturalSpec
• FsCheck
• FsTest
• FsUnit

Matthew Podwysocki a écrit un grand series sur les tests unitaires dans les langages fonctionnels . Oncle Bob a également écrit un article provoquant la réflexion here.

Answer 2

Vous pourriez jeter un oeil à FSUnit - bien que je ne l'ai pas encore utilisé, il pourrait valoir la peine d'essayer. Certainement mieux que d'utiliser par exemple NUnit (natif) en F #.

Answer 3

Je pense que c'est une question très intéressante que je me suis beaucoup posée moi-même. Mes pensées jusqu'à présent ne sont que des pensées, alors prenez-les pour ce qu'elles sont. Je pense que le filet de sécurité d'une suite de tests automatisés est un atout trop précieux pour être lâché, quelle que soit la séduction de cette console interactive, alors je prévois de continuer à écrire des tests unitaires comme je l'ai toujours fait.

L'une des principales forces de .NET réside dans ses capacités multilingues. Je sais que je vais bientôt écrire du code de production F #, mais mon plan est d'écrire des tests unitaires en C# pour faciliter mon chemin vers ce qui est pour moi une nouvelle langue. De cette façon, je peux aussi tester que ce que j'écris en F # sera compatible avec C# (et d'autres langages .NET). Avec cette approche, je comprends qu'il y a certaines fonctionnalités de F # que je peux seulement utiliser en interne dans mon code F #, mais pas d'exposer dans le cadre de mon API publique, mais je vais accepter cela, tout comme je l'accepte aujourd'hui il y a certaines choses que C# me permet d'exprimer (comme uint) qui ne sont pas conformes CLS, et donc je m'abstiens de les utiliser.

Answer 4

Jetez un oeil à FsCheck, un outil de test automatique pour F #, est essentiellement un port de QuickCheck Haskell. Il vous permet de fournir une spécification de le programme, sous la forme de propriétés que les fonctions ou les méthodes devraient satisfaire , et les tests FsCheck que les propriétés contiennent dans un grand nombre de cas générés de manière aléatoire.

FsCheck CodePlex Page

FsCheck Author Page

Answer 5

J'utilise NUnit, et il ne me semble pas difficile à lire ou à titre onéreux d'écrire:

open NUnit.Framework 

[<TestFixture>] 
type myFixture() = class 

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

end 

Depuis mon code est un mélange de F # et D'autres langues .Net, j'aime le fait que j'écris les tests unitaires de la même façon et avec une syntaxe similaire en F # et en C#.

Answer 6

Comme dglaubman suggère que vous pouvez utiliser NUnit. xUnit.net fournit également un support pour cela et fonctionne bien avec TestDriven.net. Le code ressemble à des tests NUnit mais sans l'obligation d'encapsuler le test dans un type conteneur.

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