Testing could use some improvements #699
Replies: 2 comments 2 replies
-
Hi @ghostsquad, Using in-memory filesystem sounded like a good and simple idea to me initially, but after some thought, it may actually not be so simple after all. Most files generated in tests are through commands like There's a chance that by using We could try, and if it shows to be too difficult/unreliable we would need to open an issue at mvdan/sh asking for an official support to in-memory filesystems. Even them it wouldn't be 100% because external commands would still write to the OS filesystem, of course. But for our use case (only calling builtins like |
Beta Was this translation helpful? Give feedback.
-
Did we actually test that in-memory filesystem would make things faster? If so, by how much? In principle, any modern OS kernel should be transparently caching file writes/reads in memory by default anyway (unless client explicitly decides to wait for file to be written to the backing store before confirming the IO operation). I might be wrong, but I would guess using in-memory filesystem for this wouldn't speed things up by much. |
Beta Was this translation helpful? Give feedback.
-
It looks like many of the tests for task are writing actual files to disk, and generally appear to be end-2-end tests and not unit tests. There's a lot of room to improve here, using dependency injection to inject in-memory filesystems, and other such things would allow more unit tests to be written, and also greatly improve code coverage.
Beta Was this translation helpful? Give feedback.
All reactions