If I'm not mistaken, a major part of testing software is deploying and using it on your platform of choice. For critical system software such as UNIX utils, package managers, desktop environments/window managers, kernel modules, etc., how would a developer reliably test the software without bricking their development environment?

  • 1
    If you're worried about bricking something (like a windowing system), you can run software in places other than your development environment. Like a machine dedicated for that. Or in a VM, or partitioned into a sandbox. Things like package managers are typically configurable to use alternate paths for installation, caches, etc, so they can live reasonably isolated.
    – user356474
    Commented Jan 23 at 14:16
  • Two words: virtual machine.
    – pjc50
    Commented Jan 23 at 14:28
  • Not sure why it's downvoted...
    – coteyr
    Commented Jan 23 at 14:36
  • 1
    @coteyr: some community members on this site close vote and downvote almost every question which shows not much research effort, or is very broad. Said that, this question clearly fulfills both criteria (zero research effort, and extremely broad). However, since it is one of those broad questions which can be answered in an equally broad and comprehensive way, I consider not to vote at all.
    – Doc Brown
    Commented Jan 23 at 14:44
  • I always found that odd about this SE. The questions are supposed to be broad enough that they help everyone. Yet if it's too broad, the question gets a downvote. Ask to narrow a question, and it gets a vote to close. This is a valid question if a bit "high level".
    – coteyr
    Commented Jan 23 at 14:51

2 Answers 2


You typically use a test environment that can easily be reset or rebuilt to a good state. There are different possibilities: Dedicated real machines (normally required for testing drivers), virtual machines, containers, emulators, separate filesystem paths, etc.

If you're adventurous and fully trust your backup process, you may of course test your developed software in your development environment, and restore it from backup if it breaks beyond repair. However, this is most often not the most efficient approach, as you would need to perform backups frequently so you don't lose too much.

  • 1
    Just changing to a tempdir is good enough for most software. But the Unix ecosystem has had ultra-basic containerization in the form of chroot() for the last 45 years. For example, the Debian build system uses chroot-environments to isolate dependencies.
    – amon
    Commented Jan 23 at 16:11

The answer to the question is not really OS-dependent, but at the same time, it is. For example, on Linux, you can test the window manager, and if it breaks, you don't have to reboot, whereas on Windows, there is much less separation.

That said, you test the tools much the same way as any software. Let's say you need to test a cp command line tool. You don't need to test that you actually copy a file. If you can mock things so that you are testing what fopen is called etc., that is generally "good enough" for general testing.

For lower-level things like drivers, there is nothing for it but to have a real machine with real hardware and test against that.

If you are looking at something much higher level, like "packaging tools," you still do the same thing. General testing can be done by mocking things (one way or another). For example, if you are writing apt, You might create a repo with only one package and a small manifest. Then run your tests against that.

In the end, while the toolchain will change, the concept is the same.

  • Test the most atomic thing you can.
  • Trust the libraries that are not yours (or gain trust) (no need to test fopen that's not part of your project)
  • Don't test 1s and 0s written to disk, test that the input produced the desired output (can save and read a file, not 101100110100 was written to sector 3)
  • Fake the rest. (VM, different directory, mock objects, etc)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.