2012-07-02 13 views
5

Mam pewne funkcje z plikiem skryptowym, setup.fsx Chciałbym przetestować te. xUnit i podobne potrzebuje funkcji do testowania, aby być częścią zespołu.Testy pisania dla plików skryptów w F #

Więc mam na myśli zmianę nazwy mojego skryptu z setup.fsx na rozszerzenie setup.fs, a następnie załadowanie go z innego pliku skryptu. Ale wtedy mój skrypt zależy

#r "System.Xml" 
#r "System.Xml.Linq" 

co ja wtedy trzeba określić w skrypcie wywołującym (z dala od miejsca, gdzie zależność rzeczywiście powstaje)

Czy mimo to zintegrować testy oparte na skryptach w worflow xUnit ? Jaka organizacja jest sugerowana do pisania testów dla plików skryptów?

(może być musimy wizualne rozszerzenie studio do testów w skryptach, a nie w zespole ..)

Odpowiedz

2

Nawet jeśli po prostu dodać fsx skrypt Visual Studio, nadal można skompilować setup.fsx do normalnego projektu wraz z inne (być może fs) pliki, więc powinieneś być w stanie zachować skrypt jako zwykły plik skryptu w Visual Studio i jednocześnie odwoływać się do niego z projektu lub narzędzia wiersza poleceń, które buduje twoje testy.

Próbowałem to robić z następującym test.fsx pliku:

module Demo 
#r "System.Xml.Linq.dll" 
open System.Xml.Linq 

let test() = 
    let d = XDocument(XElement(XName.Get("foo"))) 
    d.ToString() 

pewno trzeba jakąś deklarację module Name na początku (dzięki czemu można uzyskać dostęp do funkcji z innych plików), ale w przeciwnym razie może to być dowolny plik fsx . Drugim plikiem, który kiedyś był test.fs:

module Main 
open Demo  
test() |> printfn "%A" 

To jest tylko do testów, ale tutaj można pisać testy jednostkowe. Jeśli skompilować pliki za pomocą następującego polecenia, można dostać standardowego zestawu, który można przekazać do xUnit (uwaga, kompilator może odebrać #r tag z test.fsx, nie mamy napisać odwołanie wyraźnie):

fsc.exe --target:library test.fsx test.fs 

Myślę, że można uzyskać tę samą konfigurację w programie Visual Studio, jeśli dodasz projekt biblioteki, a następnie ręcznie dodaj łącze do pliku (który może wskazywać na plik w innym miejscu w strukturze rozwiązania), używając czegoś podobnego w pliku fsproj:

<Compile Include="..\Eslewhere\In\Your\Project\Tree\File.fsx"> 
    <Link>File.fsx</Link> 
</Compile> 

Pamiętaj, że po dodaniu fsx plik przy użyciu "Dodaj element", jest oznaczony jako "Uwzględnij", ale nie jako "Kompilacja", więc nie zostanie skompilowany jako część projektu. Powyższe powinno uwzględniać to w projekcie i powinno informować kompilator o włączeniu go również do skompilowanego zestawu.

Ostrzeżenie: powiedział: Myślę, że lepiej przetestować skompilowane pliki dll przy użyciu standardowych testów jednostkowych. Jeśli chcesz przetestować pliki fsx, po prostu dodaję kilka linii jako testy na końcu i uruchomię je ręcznie (wybierz, Alt + Enter). Powodem jest to, że pliki fsx powinny być często zmieniane, a więc zbyt solidne testowanie może ograniczyć Twoją elastyczność. Z drugiej strony, gdy kod staje się bardziej trwały, sensowne jest przeniesienie go do pliku dll.

+2

jeśli napiszesz moduł na górze w fsx, nie możesz go uruchomić w fsi. dodanie modułu #if COMPILED Demo #endif wydaje się być w porządku – nicolas

+0

Czy jesteś pewien, że masz dostęp do przestrzeni nazw Demo, gdy jest ona zdefiniowana w pliku fsx? Wystąpił błąd. plik fsx znajduje się powyżej na liście projektów ... błąd znika po zmianie nazwy na fs, pojawia się przełączenie z powrotem na fsx – nicolas

+0

@nicolas Próbowałem tylko uruchomić kompilator ręcznie z wiersza poleceń. Myślę, że będzie działać tylko wtedy, gdy plik 'fsx' jest oznaczony jako Kompilacja - jaka jest komenda wiersza poleceń, którą program Visual Studio drukuje w oknie" Wyjście "? Czy widzisz plik 'fsx'? –

0

Myślę, że najłatwiejszym rozwiązaniem byłoby pobranie kodu, który chcesz przetestować i umieszczenie go w osobnym pliku *.fs. W swoim skrypcie *.fsx można użyć dyrektywy #load, aby załadować kod z pliku *.fs (#load działa jak #include w języku C/C++).

Do testowania jednostkowego można utworzyć prosty projekt biblioteki F #, który zawiera plik *.fs przy użyciu <Link> (jak w odpowiedzi Tomasa), a następnie uruchomić testy jednostki przed skompilowaną biblioteką DLL.

Powiązane problemy