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 (http://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] > (mailto:[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 > > > > > > Thanks! > > > -- volanja > > > [email protected] > > > > > > 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] > > (mailto:ansible-project%[email protected]). > > To post to this group, send email to [email protected] > > (mailto:[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] > (mailto:[email protected]). > To post to this group, send email to [email protected] > (mailto:[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.
