Feature request: mockable file system?

[Fuco1]

EDIT: This functionality is now part of the assess project, check it out!

---

I have no idea how to implement this properly, but it would be really cool if I could run tests inside a "faked file system".

Couple solutions:

One solution would be to mock all the functions for file-system access to operate over some known data... the problem is finding those functions and managing their interactions. Probably the most robust solution but I think pretty much impossible to implement.

Other solution: we could just create the requested file structure on the disc (say in /tmp), set the default directory there and let the code work normally. The downside is that all the tested code would need to work with relative paths (which might not be that bad, most programs don't work with hard-coded paths anyway).

Some nice syntax to make directory structure and specify file content would also be cool.

[jorgenschaefer]

You mean some syntactic sugar for easily doing this?

(before-each
  (setq dir (make-temp-file "test-" t)
        default-directory dir))

(after-each
  (delete-directory dir t))

[Fuco1]

Well, more like something where you could specify the hierarchy in some
sort of lispy way:

(dir "contacts" 
 (file "contacts-friends" "Alice - 767 989 689\nBob - 890 334 636")
 (file "contacts-work" "Eve - 767 989 689\nDave - 890 334 636")
 (dir "stuff"
  (file "notes" "I need to write more tests!")))

So you can test your input/output on real files in a real structure.

[jorgenschaefer]

Ah, good idea. I wrote some code for that (in Python) for Elpy for just such a use case, I can totally see this being useful in Emacs, too.

[Fuco1]

I've implemented the following syntax

(with-temp-fs
    '(("foo" "content")
      (dir "bar"
        "lol"
        (dir "qux"
          ("bux" "tralala")))
      "baz")
  ;; automatically sets `default-directory' to newly generated
  ;; directory in /tmp, afterwards the original is restored and the
  ;; teporary structure is deleted
  (with-temp-buffer
    (insert-file-contents "bar/qux/bux")
    (message "%s" (buffer-string))))  ;; => "tralala"

There are four "patterns"

• a string alone is taken as a filename to touch, that is, create an empty regular file with that name.
• a list of the form (string string) is taken as a filename and content of the file.
• a list of the form (dir string patterns...) is taken as a directory with name given by the second argument. The rest of the patterns is recursively evaluated inside that directory.
• a list matching neither of above, (patterns...), is recursed over and each pattern is evaluated separately.

The spec above creates following structure:

[15:26:15]matus@herakleitos:/tmp/temp-fs-6327GpO
> tree
.
├── bar
│   ├── lol
│   └── qux
│       └── bux
├── baz
└── foo

2 directories, 4 files

The rational is that files are created most often so it should be as simple as ("foo" "bar" "baz") to create files. The more specialized content you want, the more "annoying" the syntax gets. Files with content come second and directories have to be specifically marked (but this gives us a bonus ability to (put 'dir 'lisp-indent-function '1) so they align nicely).

The syntax is extensible to further allow symlinks, with for example (sym source target) (hard and soft should both be possible), devices, pipes and all the other unix nonsense.

Tested on linux only, but uses emacs primitives so should work anywhere. Depends on f.

Should I try to polish it somehow and include in buttercup, or do you think a spearate library would be better? (I would probably prefer it in bc because it gives the user all the tools right away without need to look for yet-another-testing-related-package).

[jorgenschaefer]

That looks a lot like the syntax I created for my own uses a while back, too (for Elpy). The syntax requires some more thought, I think. I mildly dislike the dir symbol there, but I do not know if there's something better

I would like this to be included in buttercup, but I do not want to add a mandatory dependency (f.el), as that pollutes the package list for testing. E.g. you won't notice if your dependencies are missing f.el; also, if f.el ever depends on Emacs version X.Y, you will not be able to test software with buttercup that can run of earlier versions. I have seen both with ert-testrunner, and I disliked that a lot.

The two solutions to this I can see would be either to get rid of the f.el dependency, if the places where it is used are easy to replace, or add a new file to the buttercup package that can be used, but requires the buttercup user to add the f.el dependency themselves.

Thoughts?