您的位置: 首页  >  技术问答  >  流浪环境的自动化测试

流浪环境的自动化测试

分类: 技术问答 • 2022-09-23 13:37:38
问题描述：

在很多项目中，我使用Vagrant和Puppet来获得开发环境的副本。有时特别是在小型项目中，我经常需要做出改变，我重新设置了流浪盒，并且它失败了！流浪环境的自动化测试

是否有可能使用持续集成测试Vagrant框？

我需要检查框的规定没有错误，并运行一些自定义测试，如打开一个网页。

+0

您可以在这里问了几个不同的事情。你能举一个你想要做什么的例子吗？ –

+0

我希望CI运行一个流浪汉，检查退出代码，然后它应该执行一些自定义测试，如调用网页。 – SebTM

答

流浪VS其他选择进行验收测试

我细讲之前，流浪绝对是接受本地测试，因为它是超级容易安装的选择。然而，在CI环境下测试要困难得多，因为你必须设置所有不同的部分才能正常工作（Ruby，Vagrant，Virtualbox等）。 Docker是一个不错的选择，因为它是轻量级的，并且大量的CI工具都内置了基于Docker的测试（例如Travis，Gitlab CI，CircleCI）。

我会详细介绍使用Docker的here。这并不完美，因为容器不是真正的机器：你不能测试诸如sysctl或swap之类的东西。但是对于测试一个基本的Puppet模块（包，配置文件服务）来说很好。

你有什么就用它来测试你的木偶代码两个主要选择：

烧杯rspec的

烧杯在木偶由发布工程团队写入测试木偶企业堆栈的工具。后来Beaker-rspec诞生了，它为Puppet模块测试提供了更多rspec类似的体验。

你写的是这样的验收测试：

require 'spec_helper_acceptance' 

describe 'cockpit class' do 

    context 'default parameters' do 
    # Using puppet_apply as a helper 
    it 'should work idempotently with no errors' do 
     pp = <<-EOS 
     class { '::cockpit': } 
     EOS 

     # Run it twice and test for idempotency 
     apply_manifest(pp, :catch_failures => true) 
     apply_manifest(pp, :catch_changes => true) 
    end 

    describe package('cockpit') do 
     it { is_expected.to be_installed } 
    end 

    describe service('cockpit') do 
     # it { is_expected.to be_enabled } 
     it { is_expected.to be_running } 
    end 

    context 'Cockpit should be running on the default port' do 
     describe command('sleep 15 && echo "Give Cockpit time to start"') do 
     its(:exit_status) { should eq 0 } 
     end 

     describe command('curl 0.0.0.0:9090/') do 
     its(:stdout) { should match /Cockpit/ } 
     end 
    end 
    end 

end

然后运行针对选择“管理程序”的测试。所以在你的情况下，这将是流浪的，我假设使用Virtualbox。

你配置一台主机配置文件像这样：

HOSTS: 
    centos-72-x64: 
    roles: 
     - master 
    platform: el-7-x86_64 
    box: puppetlabs/centos-7.2-64-nocm 
    hypervisor: vagrant 
CONFIG: 
    type: foss

然后，使用环境变量来选择木偶版安装调用测试等（它会默认为木偶的最新版本和任何框你” VE设置为默认）：

$ PUPPET_INSTALL_VERSION="1.5.2" PUPPET_INSTALL_TYPE=agent BEAKER_set="centos-7-x64" bundle exec rake acceptance 
/Users/petersouter/.rbenv/versions/2.3.3/bin/ruby -I/Users/petersouter/.rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/gems/rspec-core-3.5.4/lib:/Users/petersouter/.rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/gems/rspec-support-3.5.0/lib /Users/petersouter/.rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/gems/rspec-core-3.5.4/exe/rspec spec/acceptance 
/Users/petersouter/.rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/gems/beaker-rspec-5.3.0/lib/beaker-rspec/helpers/serverspec.rb:43: warning: already initialized constant Module::VALID_OPTIONS_KEYS 
/Users/petersouter/.rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/gems/specinfra-2.67.2/lib/specinfra/configuration.rb:4: warning: previous definition of VALID_OPTIONS_KEYS was here 
Beaker::Hypervisor, found some vagrant boxes to create 
==> centos-72-x64: VM not created. Moving on... 
Bringing machine 'centos-72-x64' up with 'virtualbox' provider... 
==> centos-72-x64: Importing base box 'puppetlabs/centos-7.2-64-nocm'...

有大量的输出（设置我的日志详细，但你可以把它只能说明失败也有），但最终你会得到通过的测试：

这里有一个烧杯rspec的答案我介绍了Serverfault：

这里的解释烧杯的RSpec和木偶其他一些环节：

试验厨房

试验厨房实际上是一个厨师工具，但有人分叉它来支持木偶（和Ansible）。我对此没有太多经验，但本质上它的工作方式非常类似：您设置了一个配置来测试，例如Vagrant框，然后以spec文件的形式编写测试：

require 'serverspec' 

include Serverspec::Helper::Exec 
include Serverspec::Helper::DetectOS 

RSpec.configure do |c| 
    c.before :all do 
    c.path = '/sbin:/usr/sbin' 
    end 
end 

describe package('ntp') do 
    it { should be_installed } 
end 

describe service('ntp') do 
    it { should be_running } 
end

这里有几个不错的链接sumarising：

相关推荐