Написание тестов для файлов сценариев в F #

Question

У меня есть некоторые функции с файлом сценария, setup.fsx Я бы хотел протестировать их. xUnit и подобные функции нуждаются в проверенных функциях, чтобы быть частью сборки.

Так что я собираюсь переименовать свой скрипт из setup.fsx в расширение setup.fs, а затем загрузить его из другого файла сценария. Но тогда мой сценарий зависит от

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

, который я бы тогда указать в сценарии, вызывающем (от места, где фактически возникает зависимость)

Есть ли в любом случае для интеграции тестов на основе сценариев в worflow XUnit ? Какая организация предлагается для написания тестов для файлов сценариев?

(может быть нам нужно визуальное расширение студии для испытаний в сценариях, а не в сборке ..)

Answer 1

Даже если вы просто добавить fsx скрипт для Visual Studio, вы можете скомпилировать setup.fsx в нормальный проект вместе с другие (возможно, fs) файлы, поэтому вы должны иметь возможность сохранить сценарий как обычный файл сценария в Visual Studio и в то же время ссылаться на него из проекта или из инструмента командной строки, который создает ваши тесты.

Я попытался сделать это с помощью следующего test.fsx файла:

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

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

Вы, безусловно, необходимо некоторое module Name заявление в начале (так что вы можете получить доступ к функциям из других файлов), но в противном случае она может быть любой fsx файл , Другой файл, который я использовал test.fs:

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

Это только для тестирования, но здесь вы можете написать модульные тесты. При компиляции файлов с помощью следующей команды, вы получите стандартную сборку, вы могли бы перейти на XUnit (примечание, компилятор может выбрать #r тег test.fsx, мы не должны писать ссылки в явном виде):

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

Я думаю, что вы можете получить такую ​​же конфигурацию в Visual Studio, если вы добавите проект библиотеки, а затем вручную добавите ссылку на файл (который может указывать на файл в другом месте структуры вашего решения), используя что-то вроде этого в файле fsproj:

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

Обратите внимание, что при добавлении fsx, используя «Добавить элемент», он помечен как «Включить», но не как «Компиляция», поэтому он не компилируется как часть проекта. Вышеупомянутое должно включать его в проект, и оно должно сообщить компилятору также включить его в сборку сборки.

Предупреждение:, который сказал, я думаю, было бы лучше проверить только скомпилированные файлы dll с использованием стандартных модульных тестов. Если вы хотите проверить файлы fsx, я бы просто добавил пару строк в качестве тестов в конце и запустил их вручную (выберите, Alt + Enter). Причина в том, что файлы fsx должны быть изменены довольно часто, и поэтому слишком тщательное тестирование может ограничить вашу гибкость. С другой стороны, когда код становится более прочным, имеет смысл переместить его в файл dll.

Answer 2

Я думаю, что самым простым решением было бы взять код, который вы хотите протестировать, и поместить его в отдельный файл *.fs. В вашем сценарии *.fsx вы можете использовать директиву #load для загрузки кода из файла *.fs (#load работает как #include в C/C++).

Для модульного тестирования вы можете создать простой проект библиотеки F #, который включает в себя файл *.fs, используя <Link> (как в ответе Томаса), затем выполните ваши модульные тесты против скомпилированной библиотеки DLL.