Ideally your build process is completely isolated and does not muck around with the global config of your computer. The user should be able to select any paths instead of assuming that the project exists in a specific location. If the build process gathers any dependencies, these should be stored within the project directory.
If you've written such a sufficiently isolated build script, all you need to do is create a clean directory and run your build process there.
However, it is easy to overlook some dependency, so testing on the same computer does not give much confidence. You should do it anyway because it's a low-effort way to find basic problems with your build process. It's easier to debug these problems on your computer than in an unfamiliar environment.
For better results, yes you will need a second machine or a VM or some containerization technology. If you don't want to run any VMs on your computer, you still have a number of options. If this is for open-source development there are some free continuous integration services you could look into. If this is commercial development, you can surely afford to rent a virtual machine from a Cloud/Webhosting provider. For occasional testing, it is also sufficient to keep a cheap second-hand machine in your office that you remote into. E.g. I once set up a cheap Linux box with a Jenkins server that would run the complete build script every night at 2am – that way I didn't mind how slow that machine was.