Ok, that's just offensive and this thread is growing a bit religious in terms of preferences, and much less related to Ansible.
Let's take this thread elsewhere. On Tue, Dec 31, 2013 at 11:31 PM, John Dewey <[email protected]> wrote: > I personally would rather use ansible to perform integration testing. I > would rather not introduce > additional dependencies, at least additional ruby deps. The ruby > community moves very fast, and > things are often changed on a whim (e.g. robocop vs tailor, minitest vs > serverspec vs chef spec, > test-kitchen vs vagabond). I’m not hating on these projects. This is > simply my preference, and > would rather use the same tool. Especially when it gets the job done. > Sure it’s not a kewl DSL, > but meh :/ > > I made a fun example role [1] of how this could be done with ansible and > vagrant. > > [1] https://github.com/retr0h/ansible-chef_client > > John > > On Monday, December 30, 2013 at 12:09 PM, Patrick Regan wrote: > > So I’m not a super expert on this or anything, but I think I’m going to > disagree with you here. To illustrate my point I’m going to use the example > from Serverspec. > > describe package('httpd') do > it { should be_installed }end > > This is accomplished by the yum module. It will report changed, OK, or > Failed. > > describe service('httpd') do > it { should be_enabled } > it { should be_running }end > > service module… > > describe port(80) do > it { should be_listening }end > > Pretty much anything in the > Network<http://www.ansibleworks.com/docs/modules.html#network>category of > modules would work. Or doing a > local-action port connection with register > > describe file('/etc/httpd/conf/httpd.conf') do > it { should be_file } > it { should contain "ServerName www.example.jp" }end > > Stat/File/lineinfile. > ------------------------------ > > I don’t know for sure, but I was under the impression that TDD was > designed to bring a declarative-like audit format to things that aren’t > declarative. Writing modules and functions in code is not declarative, so > you write tests to ensure that behavior stays the same. In the case of > Ansible, the plays themselves are declarative. While the specs for > ServerSpec aren’t hard to follow, I find Ansible’s playbook spec much > easier to read. > > I think this comes down to the granularity of testing and what you’re > actually trying to accomplish with the tests. Checking to see if a service > is running after using the service module is rather redundant. But I can > see trying to test the application at a higher level, for example, > connecting to port 80 and making a call against your application to see > if it’s returning the right result. > > If you’re looking for a means to test another administrator, then you can > easily write your own play and see if you get any “changes” in the output. > > If you’re looking to test to see if Ansible is actually working as > advertised I see little benefit from making a testing module or framework > separate from playbooks. > > Maybe I can ask a question, as I’m still not seeing your point. How would > the spec for the testing be different than the play itself? What would a > testing module get you that a separate “testing” playbook not give you? > > > On Sat, Dec 28, 2013 at 7:59 AM, Aaron Hunter <[email protected]>wrote: > > volanja, > > Thanks for the link. serverspec looks like a good option since it has a > nice syntax and already has several suitable modules. I'd like to see an > Ansible module that could run these tests. Maybe have a 'spec' directory > under each role and be able to call them from the role's playbook. This > would add a TDD capability to Ansible. > > To those who are not convinced testing is needed in this case I would just > add that testing is always needed. Whenever you change a table constraint > in your databases you test it, when you change the VLAN config in your > switch you test it, when you write a new function in your program you test > it, when you change your DHCP config you test it. If you care about quality > the issue is not whether to test, it is only how to test. The Agile, DevOps > approach is to automate everywhere hence the need for automated CM tests > like serverspec. > > --Aaron > Blog: http://www.sharknet.us > > On Tuesday, December 17, 2013 12:03:01 PM UTC-5, @volanja wrote: > > Hi Aaron and All > > I use Severspec(introduced by shigeta) for TDD. > Now, Ansible has unit-test. but, as you say, I can not verify that the > servers are configured correctly.(e.g. setup DHCP) > ServerSpec can verify that the servers are configured correctly!! > It's popular software in Japan:) > > ServerSpec says. > Serverspec tests your servers' actual state through SSH access, so you > don't need to install any agent softwares on your servers and can use any > configuration management tools, Puppet, Chef, CFEngine and so on. > > So, I create sample (install Nginx,open port 80, and Test!) at Github. > Please check & try. > *https://github.com/volanja/ansible-sample-tdd > <https://github.com/volanja/ansible-sample-tdd>* > > Thanks! > -- volanja > *[email protected]* > > *https://twitter.com/volanja <https://twitter.com/volanja>* > > > 2013年12月12日木曜日 1時39分33秒 UTC+9 Aaron Hunter: > > I come from an Agile software development background in which test driven > development (TDD) is the norm. As I write Ansible scripts, I'd like some > way of testing them. In principle, I want to test every command in a > playbook. For example, if one of my command changes the user permissions on > a file, I want a test that independently confirms that it has in fact done > so. I don't see a "test" module but I may have missed it. > > Is that something that Ansible may offer some day? I'm thinking of the > Ansible equivalent to unit testing. I believe it would require the ability > to execute arbitrary Python code in the test. The Java tests I have written > could certainly be very complex. > > I'm also curious what others do for testing using Ansible. What > frameworks, etc. > > Thanks, > Aaron > DevOps Blog: http://www.sharknet.us > > -- > You received this message because you are subscribed to the Google Groups > "Ansible Project" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > For more options, visit https://groups.google.com/groups/opt_out. > > > -- > You received this message because you are subscribed to the Google Groups > "Ansible Project" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > For more options, visit https://groups.google.com/groups/opt_out. > > > -- > You received this message because you are subscribed to the Google Groups > "Ansible Project" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > For more options, visit https://groups.google.com/groups/opt_out. > -- Michael DeHaan <[email protected]> CTO, AnsibleWorks, Inc. http://www.ansibleworks.com/ -- You received this message because you are subscribed to the Google Groups "Ansible Project" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
