unit testing - tipos - F#desarrollo y pruebas unitarias?
testing unitario software (6)
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 funcionen, y ajustar y 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.
Como dglaubman sugiere, puedes 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)
Creo que esta es una pregunta muy interesante que me he preguntado mucho sobre mí misma. Mis pensamientos hasta ahora son solo pensamientos, así que tómelos como lo que son.
Creo que la red de seguridad de un banco de pruebas automatizado es un activo demasiado valioso como para dejarlo ir, por atractiva que sea la consola interactiva, así que planeo continuar escribiendo pruebas de unidades como siempre lo he hecho.
Una de las principales fortalezas de .NET son las capacidades de lenguaje cruzado. 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é, así como acepto hoy que hay ciertas cosas C # me permite expresar (como uint ) que no cumple con CLS, por lo que me abstengo de usarlos.
Eche un vistazo a 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 una gran cantidad de casos generados aleatoriamente.
Los desarrolladores basados en pruebas deberían sentirse como en casa en lenguajes funcionales como F #: pequeñas funciones que dan resultados determinísticamente repetibles se prestan perfectamente a 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 usar las mismas herramientas y trucos que utiliza al hacer TDD en C #. También hay algunas herramientas de prueba escritas o específicamente para F #:
Matthew Podwysocki escribió una gran series sobre pruebas unitarias en lenguajes funcionales. El tío Bob también escribió un artículo que invita a la reflexión here .
Podrías echarle 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 #.
Uso NUnit, y no me parece tan difícil de leer ni oneroso escribir:
open NUnit.Framework
[<TestFixture>]
type myFixture() = class
[<Test>]
member self.myTest() =
//test code
end
Como 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 #.