

Support for Test-Driven Devops - dogweather
http://robb.weblaws.org/2014/01/16/new-open-source-library-for-test-driven-devops/

======
falcolas
I like the idea of asserting "here is what my environment should look like,
and how it should behave."

However, What is the advantage of this over a configuration management tool
(puppet, salt, chef, ansible, etc)? You can make similar operational state
assertions with a CMS, and better, it will fix any problems it encounters when
running.

~~~
makerops
It doesn't always though, with chef/puppet et al, you can write the code to
throw up X (aapche w/ ssl etc), but unless you use a testing facility, there
is no way to know for sure (other than manually checking obviously).

~~~
falcolas
You can dictate that a service is running, and it will ensure that the service
is running. You can also set up more advanced HTML checks in at least some
frameworks[1] to ensure that the contents are being served correctly.

[1]
[http://docs.ansible.com/get_url_module.html](http://docs.ansible.com/get_url_module.html)
&
[http://docs.ansible.com/uri_module.html](http://docs.ansible.com/uri_module.html)
for ansible, I'm fairly certain you can build up something similar for puppet
and chef, though I haven't done it myself.

~~~
sandfox
Writing code/recipes/etc for chef/ansible/puppet is no different to writing
code for an application. Just because you think you have dictated (in code)
that things should be a certain way does not mean that what will be executed
or run.

~~~
falcolas
The exact same caveats could be applied to unit testing an environment. Common
sense and practical tests rule any form of automation.

------
skywhopper
Brilliant post and brilliantly timed for me as I've been thinking about ways
to expand my own operations test suite into the realm of web service behavior.

To address the folks who say just use Nagios, well I say use the right tool
for the job and the right tool for your existing processes. For some
environments and tasks Nagios is a great choice. For others a scripted Rspec
style solution is more appropriate.

And for still others (like mine) a combination of a traditional monitoring
system with some scripted TDD-style tests (which can also tie into the central
monitoring agent, btw) is the right solution.

------
stigi
A friend build a tool called hyperspec that can be used to create integration
tests on your HTTP APIs.

[https://github.com/hannestyden/hyperspec](https://github.com/hannestyden/hyperspec)

------
rmc
Sounds like you should just use Nagios or some other network monitoring
system.

Nagios is very valuable when you're recovering from a disaster. Just keep
doing things until it all turns green! It's just like refactoring.

~~~
dogweather
I'm a little skeptical of it; it seems very complex. In contrast, I'm
leveraging the Ruby+RSpec infrastructure which I've already learned. And I
interact with it via programming, instead of via configuration.

Also, by using just one language, Ruby, I can easily have full test coverage
of the framework code itself. There are a lot of nagios plugins and scripts
out there, but they don't seem to usually include tests of themselves.

But nagios is very intriguing - I'll check out what a "simple" install would
be like.

~~~
talkingquickly
For smaller apps is worth looking at Monit, really simple to setup and covers
most of what needs testing if configured correctly.

------
tehskylark
This reminds me a lot of the open source project GAUNTLT. I'd highly recommend
it. [http://gauntlt.org/](http://gauntlt.org/)

