Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Look into stabler methods of integration testing #23

Open
unwitting opened this issue Sep 29, 2015 · 6 comments
Open

Look into stabler methods of integration testing #23

unwitting opened this issue Sep 29, 2015 · 6 comments

Comments

@unwitting
Copy link
Collaborator

More of a suggestion ticket really - one idea I had that might help to get around all the messiness of still-mounted FSs after failed cases etc etc is to run within Docker containers. A simple image which pretty much just has fuse installed would serve the purpose and would allow the test framework to trash and rebuild a clean state much more reliably.

@Munter
Copy link
Owner

Munter commented Sep 29, 2015

I'm a complete docker newbie, so I'm not quite sure how to approach that yet.

@mafintosh what did you do in all your fuse work to avoid these locked up file system states?

@mafintosh
Copy link

@Munter i usually try to have my fuse stuff be very minimal so there will be fewer crashes and then maybe run that as a daemon that something more advanced interface with. Running it inside docker is non-trivial since it requires privileged access to mount drives.

In my fuse-bindings tests i always unmount + mount in the tests on every testcase to work around this problem as well. Fx, https://github.com/mafintosh/fuse-bindings/blob/master/test/write.js (adding the force option makes it unmount first)

@unwitting
Copy link
Collaborator Author

Wow, I really thought to myself "oh, the point of fuse is that it can be run in user space with user priveleges, so it'll be cool in a Docker container even without using a root user within the container". But now you said that, a quick search says you have to get involved with altering picky configs to make this work. Never mind, that's probably more trouble than it's worth :\

@unwitting
Copy link
Collaborator Author

But +1 for mounting before and unmounting after every test, I think this is a necessary step.

@Munter
Copy link
Owner

Munter commented Sep 30, 2015

I'm already mounting and unmounting per file in test/. However I think it might make sense to not mount a mirror of the entire fixtures directory, but instead mount an empty one, then copy over one file at a time per test and remove it when done. That would reduce the amount of crazyness coming from file indexer discoveries and possibly other side effects

@unwitting
Copy link
Collaborator Author

The test I submitted for the other bug in PR #24 (I think) does nearly that

  • there's a 'tmp' dir in fixtures which is gitignored where I copy a file
    from fixtures. Could easily mount only that, clear it and set it up with
    specific files before a test.

On Wed, 30 Sep 2015 09:09 Peter Müller [email protected] wrote:

I'm already mounting and unmounting per file in test/. However I think it
might make sense to not mount a mirror of the entire fixtures directory,
but instead mount an empty one, then copy over one file at a time per test
and remove it when done. That would reduce the amount of crazyness coming
from file indexer discoveries and possibly other side effects


Reply to this email directly or view it on GitHub
#23 (comment).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants