http://dustinrcollins.com/chef-integration-testing-with-serv...
If you use it in a pipeline and it reports no errors, you can then upload your cookbook changes to chef server and bump the version. Obviously it relies on cookbook writers being disciplined, to make sure they add tests for new features they have added, but even a simple test to make sure a service is up and running and listening on a port can be enough to make sure a commit has not broken a cookbook.
Opscode recently announced chef compliance which appears to build on serverspec, it is more geared towards auditing and security.
The problem I ran into was where I wanted to test service restarting in a systemd based environment. Older releases using sysvinit work perfectly fine.
Also. If you're on upstart, give lxc a shot. We currently test our ansible scripts by deploying to lxc by giving each container a static IP in a bridged network to simulate our production environment. Just swap ansible inventory files. Works like a charm.
It should be simple enough to adjust to run ansible.
I've been playing around with the technique a while, but a different contributor ultimately did the final work for me, and he wrote up a great blog post on the process: http://bertvv.github.io/notes-to-self/2015/12/13/testing-ans...
While I'm yet to find a compelling reason for me to use Docker for my production environments (though the is one SaaS service I run which may benefit as Docker's warts have become much more manageable), it's excellent in a CI environment!
I can write my cookbooks and almost instantly test them inside a container. You can even test on multiple platforms at the same time (Debian,Rhel etc) in parallel. You can perform integration testing using serverspec once the container has converged to the required state - http://serverspec.org/