This project has moved and is read-only. For the latest updates, please go here.

Path to csv folder?

Dec 31, 2013 at 7:06 PM
Edited Dec 31, 2013 at 8:21 PM
I understand Effort is still in Alpha - which I take to mean that there are still features you would like to add. So don't consider this a complaint, but rather an opening of a discussion.

I like my unit test assemblies to be standalone, not depending on external files to the extent that is possible. I see no advantage to being able to swap out the load.csv files, at runtime.

Currently, I'm including a csv file directory in my test assembly's project, and specifying it relative to Assembly.GetExecutingAssembly(). Which means that my tests will only run if the test assembly is executed from within its build directory tree.

I'd prefer to embed my csv files into my assembly, and extract them from there. I could embed the individual files, but .NET's embedded resources mechanism doesn't seem to support embedding directory trees.

The best suggestion I've seen is to embed a zip file, and to extract the directory at runtime. And that's enough of a kludge that I'm sticking with the relative paths, for now.

Still, when you next look at the csv loading functionality, would you please consider how you might make these files work as embedded resources?

========= ADDENDUM =========

I just discovered that my approach of using a path relative to my test assembly to find the csv files does not work, when my tests are run from the command-line, using MsTest. MsTest copies the assembly under test, and its dependencies, to an "Out" subdirectory, so that they run in isolation. From there, of course, the relative paths don't resolve.

There are solutions to this, but they are all far more complicated than I would like.
Jan 11, 2014 at 2:01 PM
Edited Jan 11, 2014 at 2:04 PM
Hello,

Thank you for your suggestions!

My current recommendation is to set the Copy to Output directory property of the csv files. Then you can locate these files like this:
var dir = AppDomain.CurrentDomain.BaseDirectory;
var file = Path.Combine(dir, "data\\table.csv");

Assert.IsTrue(File.Exists(file));
However, I like your idea so and will consider implementing support for embedded resources. I don't know what you mean by "support embedding directory trees", but you can select multiple files in Solution Explorer and set their Build Action property to Embedded Resource at once. Then you can query the location of these resources like this:
AppDomain
    .CurrentDomain
    .GetAssemblies()
    .Where(asm =>
        asm.FullName.StartsWith("test, Version=1.0.0.0"))
    .SelectMany(asm => 
        asm.GetManifestResourceNames())
    .ToList();
In this way Effort could find the specified resources. Currently I see no point of supporting zip files too.
Jan 13, 2014 at 3:31 PM
My understanding was that when you're using CSV files, you don't pass the individual files to Effort, you pass the name of a directory containing the individual files. And while you can embed individual files as resources within an assembly, you cannot embed a directory.

What I could do now is to embed the individual files, and then on initialization I could create a temporary directory, extract the individual files into that directory, and pass the temporary directory to Effort.

If I could pass a list of CSV filenames to Effort, instead of the name of a directory, then I could build a list from the embedded resources as you describe above.

I don't remember seeing an option for initializing Effort with a list of CSV filenames. Did I miss it in the documentation? Or is it new, and not yet in the documentation? Or is it a new functionality that you are considering?

If it doesn't already exist, it would probably be the simplest and cleanest mechanism for dealing with the issue.
Jan 25, 2014 at 11:03 PM
I have implemented this feature, check the newly added CsvDataLoader_EmbeddedResource tests.

You only have to specify the directory of the embedded resource files, the data loader will find the embedded CSV files.