I’ve used FSI for running unit tests, but it involves a bit of setup work, and it has plenty of caveats so the experience isn’t that great. But it does speed up my feedback time pretty significantly in some cases. Basically, I’ll have a Packages.fsx file in the root folder that just has a bunch of
#r "path/to/whatever/package.dll" lines for each package (I don’t use the #r "nuget: ..." syntax here because it’s so much slower). You might be able to use paket’s “generate load scripts” feature to make this simpler.
Then for each project file I have a Proj.fsx file that will pretty much look like
#load "../Packages.fsx"
#r "bin/Debug/net6.0/projA.dll"
#r "bin/Debug/net6.0/projB.dll"
so just include the project you’re in plus all the dependent projects (note these have to be loaded in order, or things will break).
Then finally you can setup the test file - let’s say I have a BunchOfLogic.fs file and a BunchOfLogicTest.fs file. In BunchOfLogicTest.fs, I’ll have
#if compiled
module BunchOfLogicTest
#else
#load "Proj.fsx"
#load "BunchOfLogic.fs"
#endif
Then I can load it into an FSI session with dotnet fsi --load:BunchOfLogicTest.fsx, and any changes I make to BunchOfLogic or BunchOfLogicTest, I can just #q;; from my FSI window and rerun the dotnet fsi --load:BunchOfLogicTest.fs command again. Note that this will only pickup changes to the BunchOfLogic.fs and BunchOfLogicTest.fs - any other changes will require you to compile the project again, so it’s really only suitable for unit tests. Sometimes if only the test file changed, I’ll just highlight from the change down and hit alt+enter to rerun that section in FSI.
I’ve found dotnet fsi --load:file.fs to often have a much faster startup time than dotnet test, but as is probably obvious, it seems that FSI was never really designed for this sort of use, so it’s clunky, and sometimes it’s pretty easy to get confused. I can’t say I really recommend this approach. I’m hoping this feature request will get implemented at some point, which I think would make the situation a lot easier to work with.
You might also want to play around with stuff like dotnet build --no-dependencies && dotnet test --no-build to try and speed things up.