I have some functionality withing a script file, setup.fsx
I would like to test those.
xUnit and the likes needs the functions to be tested to be part of the assembly.
So I am thinking of renaming my script from setup.fsx to setup.fs extension, then loading it from another script file. But then my script depends on
#r "System.Xml"
#r "System.Xml.Linq"
which I would then have to specify in the calling script (away from where the dependency actually arises)
Are there anyway to integrate tests based on scripts in the xUnit worflow ?
What organization is suggested for writing tests for script files ?
(may be we need a visual studio extension for tests in scripts and not in assembly..)
Even if you just add
fsxscript to Visual Studio, you can still compilesetup.fsxinto a normal project together with other (possiblyfs) files, so you should be able to keep the script as a normal script file in Visual Studio and, at the same time, reference it from a project or from a command line tool that builds your tests.I tried doing that with the following
test.fsxfile:You definitely need some
module Namedeclaration at the beginning (so that you can access functions from other files), but otherwise it can be anyfsxfile. The other file that I used wastest.fs:This is just for testing, but here you could write your unit tests. If you compile the files with the following command, you get standard assembly that you could pass to xUnit (note, the compiler can pick the
#rtag fromtest.fsx, we do not have to write the reference explicitly):I think you could get the same configuration in Visual Studio if you add a library project and then manually add link to the file (which can point to a file elsewhere in your solution structure) using something like this in the
fsprojfile:Note that when you add
fsxfile using “Add Item”, it is marked as “Include” but not as “Compile”, so it does not get compiled as part of the project. The above should include it in the project and it should tell the compiler to include it in the compiled assembly too.Warning: that said, I think it might be better to test just compiled
dllfiles using standard unit tests. If you want to testfsxfiles, I would just add a couple of lines as tests at the end and run them by hand (select,Alt+Enter). The reason is thatfsxfiles are supposed to be changed quite often and so having too solid testing may limit your flexibility. On the other hand, once code gets more solid, it makes sense to move it to adllfile.