2009-09-23 29 views
14

Come si creano i test unitari in F #? In genere utilizzo la parte UnitTest di Visual Studio con gli attributi [TestClass] e [TestMethod] e utilizzo la Vista test per eseguirli. So che posso solo creare un file di script ed eseguirli, ma mi piace il modo in cui è attualmente gestito.Come gestire i test unitari in F #?

+0

[Questo mio recente articolo] (http://fsharpnews.blogspot.com/2011/01/testing-behaviour-driven-development.html) ha descritto questo e molto altro (test BDD da F #). –

+0

Ecco un punto di partenza: http://bit.ly/1JhEbA7 –

risposta

9

Preferisco utilizzare FsUnit o FsTest per scrivere i test in F #, ci si sente più naturale rispetto OO xUnit test di stile.

EDIT 2014: Ora considero FsUnit/FsTest lo zucchero di sintassi per lo più inutile. E "più naturale di OO" non significa assolutamente nulla. Alcuni mesi fa ho scritto le mie attuali riflessioni sul test here (consiglio di leggere l'intero thread).

10

Check out fscheck. È una porta di Quickcheck di Haskell. Fscheck consente di specificare le proprietà che una funzione deve soddisfare e che quindi verificherà in base a "un numero elevato di casi generati casualmente".

È qualcosa che non si può fare facilmente con un linguaggio imperativo come C#.

+0

Dai un'occhiata a Pex: http://research.microsoft.com/en-us/projects/Pex/ –

+0

@Mauricio: Sono d'accordo che è possibile fare ciò che fa FsCheck (generare casualmente casi di test) in un'impostazione OO (un altro esempio: RANDOOP). Forse un giorno avremo un linguaggio specifico (che sembra molto più bello in un ambiente funzionale nel mio parere molto prevenuto) che può generare sia casi casualmente generati che casi di copertura come Pex. –

+0

Ora FsCheck ha un'interfaccia C# in modo da poter utilizzare anche le funzionalità più importanti di FsCheck in C#. –

1

Prova XUnit.net

+0

concordato. (solo?) xUnit.NET è in grado di eseguire test case in metodi statici, quindi se si vuole rimanere nei tradizionali framework di test delle unità .NET, è quello che richiede il minimo sforzo. –

+0

MbUnit può fare anche questo –

1

A partire dalla versione 2.5, NUnit consente di utilizzare static members as tests. Inoltre, TestFixtureAttribute di livello classe è only necessary for generic or classes with non-default constructors. NUnit ha anche un backward-compatible convention che un membro del test può iniziare con la parola "test" invece di usare TestAttribute, quindi puoi quasi scrivere F # idiomatico con NUnit> 2.5.

Aggiornamento È possibile vedere alcuni esempi di test senza il TestFixtureAttribute nel Cashel library. Ho continuato a utilizzare il TestAttribute poiché sembra che pochi test runner raccolgano correttamente i test quando non sono presenti, in modo che parte del messaggio NUnit possa essere errata o almeno fuorviante.

+0

Ryan, ti piacerebbe elaborare un test di esempio in F #? O un link a un sito che mostra i test di unità F # senza TestAttribute o TestFixtureAtrribute? –

+0

@David Ho aggiunto un collegamento ai miei test per Cashel. –

3

io uso una combinazione di xUnit.net, TestDriven.Net (Visual Studio Add-in per l'esecuzione di test, gratuito per "gli studenti, gli sviluppatori open source e gli utenti di prova"), e la mia libreria proprio open source Unquote (che funziona anche con NUnit e qualsiasi altro assertion framework basato su eccezioni). Questo ha funzionato alla grande ed iniziare è davvero semplice:

  1. Scaricare e installare TestDriven.Net
  2. Scarica xUnit.net, Unzip in qualsiasi posizione ed eseguire xunit.installer.exe di integrarsi con TestDriven.Net
  3. Scarica Unquote, decomprimere qualsiasi posizione
  4. Creare un progetto all'interno della vostra soluzione per unit test
  5. aggiungere riferimenti a xunit.dll e Unquote.dll (dai download decompressi) nel progetto di test di unità
  6. Quello che segue è un semplice esempio di file .fs nel progetto di test dell'unità contenente i test delle unità di stile xUnit.net/Unquote.

    module Tests 
    open Swensen.Unquote 
    open Xunit 
    
    [<Fact>] 
    let ``description of first unit test``() = 
        test <@ (11 + 3)/2 = String.length ("hello world".Substring(4, 5)) @> 
    
    [<Fact>] 
    let ``description of second unit test``() = 
        let x = List.rev [1;2;3;4] 
        x =? [4;3;1;2] 
    
  7. eseguire tutti i test di unità nel progetto facendo clic destro del progetto in Esplora soluzioni e selezionando Esegui test (s).Entrambi i precedenti test di esempio non riuscirà con all'interno stampato alla finestra Output di Visual Studio:

    ------ Test started: Assembly: Tests.dll ------ 
    
    Test 'Tests.description of second unit test' failed: 
    
    [4; 3; 2; 1] = [4; 3; 1; 2] 
    false 
    
        C:\Solution\Project\Tests.fs(12,0): at Tests.description of second unit test() 
    
    Test 'Tests.description of first unit test' failed: 
    
    (11 + 3)/2 = String.length ("hello world".Substring(4, 5)) 
    14/2 = String.length "o wor" 
    7 = 5 
    false 
    
        C:\Solution\Project\Tests.fs(7,0): at Tests.description of first unit test() 
    
    0 passed, 2 failed, 0 skipped, took 1.09 seconds (xUnit.net 1.7.0 build 1540). 
    
7

In VS2013 è possibile utilizzare il seguente.

open Microsoft.VisualStudio.TestTools.UnitTesting 
[<TestClass>] 
type testrun() = 
    [<TestInitialize>] 
    member x.setup() = 
     //your setup code 

    [<TestMethod>] 
    member x.yourTestName() = 
     //your test code 

Suggerimento: se si sta cercando il test dell'unità UI, è possibile utilizzare questa configurazione con Canopy.

+1

Questa dovrebbe essere la risposta accettata. Questo utilizza la funzionalità di test dell'unità integrata. Inoltre (e non ovviamente), questo approccio richiede l'aggiunta di un riferimento a Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll. – wizulus

+0

@alancnet è integrato solo se stai usando Visual Studio. – Yawar