Reading test data from files, instead of resources

[mcavigelli]

Hello Robert

I have read your blog post http://blog.codeinside.eu/2015/03/03/keep-your-testdata-with-your-tests/.
I often read from the file system:

• text files
• embedded databases

My test usually read directly from the file:

• Easier to read from file then from an embedded resource
• Probably faster to read from file
• test-dll is not getting big with embedded files (could be large)

Matthias

[robertmuehsig]

Mhhh... ok, this seems not much harder then the "embedded" resource style and you are right, with each new test-file the assembly will grow, but I'm not sure if this is a problem. At least the tests can't run without the testdata.

On the "pro-embedding" stuff I don't have to worry about "file" conflicts with multiple testprojects (and the same output folder, like here https://github.com/Code-Inside/Sloader/blob/master/build/build.fsx#L31).
I guess you avoiding this by creating one output folder per test, right?

[mcavigelli]

Msbuild does the work. Having this file structure in the test project

tests/Sloader.Tests/FeedCrawlerTests/Samples/GitHubAtom.xml

is being copied to

 artifacts/tests/FeedCrawlerTests/Samples/GitHubAtom.xml

For one test project, no clash is possible as the whole directory tree below

 tests/Sloader.Tests

is being copied to the test directory. If you have several test projects which are
being copied to the same directory, files might override each other.
I haven't thought about this before.

On the "pro move file side" I can add, that running the tests is a little faster: on my machine around 6.5s instead of 7.5s.

[robertmuehsig]

Currently the build script builds a single messy directory, with potential file conflicts (besides other problems), when I fix this line (but currently my FAKE/F# Voodoo is too low) https://github.com/Code-Inside/Sloader/blob/master/build/build.fsx#L34 I will merge your pull request and add some notes to my blogpost. I think your solution is cleaner :)

[robertmuehsig]

Thanks for the PR! I reintroduced the TestHelper just to have one single way to access the test files. I will also update the blogpost that this is also quite possible and maybe cleaner.
Thanks to a previous PR the testprojects are now build in seperate directories, so I'm really happy with this approach.
Thanks!