F # desarrollo y pruebas unitarias?

Question

Acabo de empezar con F #, que es mi primer lenguaje funcional. He estado trabajando casi exclusivamente con C#, y disfruto mucho de cómo F # me lleva a volver a pensar cómo escribo el código. Un aspecto que encuentro un poco desorientador es el cambio en el proceso de escribir código. He estado usando TDD durante años en C# ahora, y realmente aprecio tener pruebas unitarias para saber dónde estoy.

Hasta ahora, mi proceso con F # ha sido escribir algunas funciones, jugar con ellas con la consola interactiva hasta que esté "razonablemente" seguro de que funcionan, y ajustar & combinar. Esto funciona bien en problemas de pequeña escala como el Proyecto Euler, pero no puedo imaginar construir algo grande de esa manera.

¿Cómo se acercan las personas a las pruebas unitarias y crean un conjunto de pruebas para un programa F #? ¿Hay un equivalente a TDD? Cualquier punteros o pensamientos son apreciados.

Answer 1

Los desarrolladores basados ​​en pruebas deben sentirse como en casa en lenguajes funcionales como F #: las funciones pequeñas que dan resultados determinísticamente repetibles se prestan perfectamente a las pruebas unitarias. También hay capacidades en el lenguaje F # que facilitan las pruebas de escritura. Tome, por ejemplo, Object Expressions. Puede escribir fácilmente falsificaciones para funciones que toman como entrada un tipo de interfaz.

En todo caso, F # es un lenguaje orientado a objetos de primera clase y puede utilizar las mismas herramientas y trucos que utiliza al hacer TDD en C#. También hay algunas herramientas de pruebas escritas en o específicamente para F #:

• NaturalSpec
• FsCheck
• FsTest
• FsUnit

Mateo Podwysocki escribió un gran series en la unidad de pruebas en los lenguajes funcionales . Tío Bob también escribió un artículo que invita a la reflexión here.

Answer 2

Podrías echar un vistazo a FSUnit - aunque aún no lo he usado, podría valer la pena intentarlo. Ciertamente mejor que usar, por ejemplo, NUnit (nativo) en F #.

Answer 3

Creo que esta es una pregunta muy interesante que me he preguntado mucho. Mis pensamientos hasta ahora son solo pensamientos, así que tómelos como lo que son.

Creo que la red de seguridad de un conjunto de pruebas automatizado es un activo demasiado valioso para dejarlo ir, por atractiva que sea la consola interactiva, así que planeo continuar escribiendo pruebas de unidad como siempre lo he hecho.

Una de las principales fortalezas de .NET son las capacidades de idiomas cruzados. Sé que voy a escribir código de producción de F # pronto, pero mi plan es escribir pruebas de unidad en C# para abrirme paso en lo que para mí es un nuevo idioma. De esta forma, también puedo probar que lo que escribo en F # será compatible con C# (y otros lenguajes .NET).

Con este enfoque, entiendo que hay ciertas características de F # que solo puedo usar internamente en mi código F #, pero no las expongo como parte de mi API pública, pero lo aceptaré, tal como lo acepto hoy. hay ciertas cosas que C# me permite expresar (como uint) que no cumplen con CLS, por lo que me abstengo de usarlas.

Answer 4

Tenga una mirada en fscheck, una herramienta de prueba automática para F #, es básicamente un puerto de QuickCheck de Haskell. Le permite proporcionar una especificación del programa , en forma de propiedades que las funciones o métodos deben cumplir , y FsCheck prueba que las propiedades se mantienen en un gran número de casos generados aleatoriamente .

FsCheck CodePlex Page

FsCheck Author Page

Answer 5

utilizo NUnit, y no me parece que sea difícil de leer o onerosa para escribir:

open NUnit.Framework 

[<TestFixture>] 
type myFixture() = class 

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

end 

Desde mi código es una mezcla de F # y otros lenguajes .Net, me gusta el hecho de que escribo las pruebas unitarias básicamente de la misma manera y con una sintaxis similar tanto en F # como en C#.

Answer 6

Como dglaubman sugiere que puede usar NUnit. xUnit.net también proporciona soporte para esto y funciona bien con TestDriven.net. El código es similar a las pruebas de NUnit pero sin el requisito de ajustar la prueba en un tipo contenedor.

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