I'd like to contribute to the project, and I'd like to know what's your development setup.
I'm using an Arch Linux box. I can modify code and run tests from there but both because auto-installer wasn't available for my distribution and because I didn't want to mess with my main machine, I've installed pihole in a vagrant virtual machine that's visible in my LAN.
It works, but it sounds a bit complicated: I don't think core contributors have to test new code.
Any suggestion?, what's your setup?
Are you asking us, the developers, how to test in development?
If so, most of us have taken to using Digital Ocean or Vultr for quickly spinning up a VM of each OS we support, and then running the installation script. Personally, I've also used Parallels to spin up VMs locally for testing.
We also all have Raspberry Pi's, which is where Pi-hole has it's roots, but testing is a bit more tedious there due to flashing the SD cards back to a clean state.
We encourage users to play and test in development via the pihole checkout command, with the understanding that it's not production-ready and is not always stable, but via that command, we have made it quite simple to switch back and forth between development and master branches.
It actually helps us a lot when we get feedback from our users. Since this is more technical, we typically keep the discussion over on GitHub, but we may consider making a new Development Feedback category here on discourse.pi-hole.net.
Personally, I've also used Parallels to spin up VMs locally for testing.
How do you test the changes you just commited? autotest starts two Docker containers and it's doing the testing there - making ineffective the use of VMs.
So you copy the repository to the VM in Parallel, install pihole and open the browser waiting to trigger ads, correct?
I develop on my Pi hardware directly. Side effect: If I break something, I will immediately notice 
Same here. I do test changes through DO sometimes, depending on their nature.
Same ...
but noticed yesterday, after again totally derailing Pi, how convenient it is to have Btrfs and restore a previous snap from before I f.cked up
The tests that we have cover only a very small portion of one script, and the developers write the tests. Core contributors very much have to test their code, and most of it is done via running the scripts and checking to see what the outcome is. Hope to move more to the testing rig as we go along.
As for me personally, Arch Linux is my daily driver as well, I'll spin up virtual environments or use DO and Vultr. Vagrant is a good solution, I'm libvirtd so I can just mutate a box and up a VM.
It is a bit complicated, but we're working on solutions to make it a little more friendly.
This came dropping on my lap a few years ago:
Running fine in a Xen domain emulating arm etc to build.
Have thought about Jenkins and kind of ran into a situation of not really using it, since we script and the only binaries that we build are FTL which is Travis. Hard to test bash scripts but if you have any suggestions on how we could better use a tool like Jenkins, we'd love to hear them.
Monkey see monkey do is my motto.
Have a look at the different aspects/jobs scheduled or hooked by jenkins.
Allot can be copied/modded/applied for your needs.
http://jenkins.xbian.org/job/xbian-package-cec/ws/
EDIT: this is better example:
I also like to have one machine that is an existing install, and one clean install so I can test for issues new and existing users may run into.