Статьи

BDD с Vagrant — возьми 2

Декабрь 9, 2018

Большое спасибо Atlassian за предоставленную мне возможность опубликовать этот сериал !!

Запуск тестов из виртуальной машины

После того, как я рассмотрел Puppet Unit Testing , логичный шаг — написать о поведенческом тестировании .

При написании этого я могу привести хороший пример того, почему BDD должен дополнять ваши модульные тесты: я установил Apache Puppet Module, и все условия работали нормально. Пока я не протестировал веб-страницу с помощью lynx http: // localhost, я понял, что мне нужно создать веб-сайт по умолчанию. Это, конечно, тривиальный пример, но я покажу вам, что BDD может помочь вам в тестировании логических ошибок.

Когда возникает эта тема, большинство людей знакомы с Cucumber Nagios . Он содержит серию шагов Cucumber, которые позволяют протестировать http-запрос, amqp, dns, ssh, command.

Из того, что я обнаружил, большинство людей будут выполнять эти тесты на виртуальных машинах напрямую. Это требует, чтобы вы установили огурец и все его драгоценные камни в VM. Gareth RushGrove написал отличный пост в блоге по упаковке огурцов-нагио с fpm

Запуск тестов со стороны ВМ — Take 1

В некоторых ситуациях необходимые гемы, библиотеки могут приводить к конфликтам или вводить зависимости, которых вы бы не хотели иметь на своей рабочей машине. И они станут еще одним пунктом для технического обслуживания ваших производственных машин.

Итак, в предыдущем посте Vagrant Testing, Testing One Two , я уже описывал использование модифицированных шагов Cucumber-Nagios, которые взаимодействуют с Vagrant через ssh.

Запуск тестов со стороны ВМ — Take 2

Но у меня была проблема с предыдущим подходом. В зависимости от ситуации мне нужно было бы запускать одни и те же тесты с помощью разных методов подключения: vagrant использует ssh, ec2 через fog, openvz через vzctl и т. Д …

Поэтому я предложил новый гибкий подход: используйте настраиваемую команду для подключения к виртуальной машине и выполните те же действия.

С небольшой помощью Арубы

В то время как Cucumber-Nagios медленно продвигается в Cuken , шаги SSH получают преобразованные шаги Арубы для локального освобождения. И в сочетании с ssh-forever шагами для ssh-взаимодействия.

Драгоценный камень Aruba — это набор CLI Steps для огурца . Вы можете использовать его для интерактивного взаимодействия с процессом или просто запустить. Примеры шагов могут выглядеть так:

Given I run "ssh localhost -p 2222" interactively
And I type "apache2ctl configtest"
And the exit status should be 0

Делая это соединение нейтральным

Как вы можете видеть на предыдущем шаге, в функции все еще есть соединение. Не здорово, если мы хотим запустить его локально. Я перефразировал это:

Feature: apache check

  Scenario: see if the apache header is served
    Given I execute `lynx http://localhost --dump` on a running system
    Then the output should match /It works/
    Then the exit status should be 0

  Scenario: check if the apache config is valid
    Given I execute `apache2ctl configtest` on a running system
    Then the exit status should be 0

Написание логики

Вот логика, чтобы заставить это работать (поместите это в features / support / step_definitions / remote_system_connect_steps.rb . Он использует две переменные окружения:

SYSTEM_EXECUTE: the command to execute just one command
SYSTEM_CONNECT: the command to connect to the system

Примером для vagrant будет:

SYSTEM_EXECUTE: "vagrant ssh_config | ssh -q -F /dev/stdin default"
SYSTEM_CONNECT: "vagrant ssh"

Это может быть также ваш любимый нож ssh, vzctl 33 enter, mc-ssh somehost

When /^I execute `([^`]*)` on a running system$/ do |cmd|
  @execute_command=ENV['SYSTEM_EXECUTE']
  @connect_failed=false
  unless @execute_command.nil?
    steps %Q{ When I run `#{@execute_command} "#{cmd}"` }
  else
    @execute_failed=true
    raise "No SYSTEM_EXECUTE environment variable specified"
  end
end

When /^I connect to a running system interactively$/ do
  @connect_command=ENV['SYSTEM_CONNECT']
  @connect_failed=false
  unless @connect_command.nil?
    steps %Q{
        When I run `#{@connect_command}` interactively
    }
  else
    @connect_failed=true
    raise "No SYSTEM_COMMAND environment variable specified"
  end
end

When /^I disconnect$/ do
  steps %Q{ When I type "exit $?" }
end

Обезьяна Ямочный Аруба

По умолчанию Аруба использует shellwords для анализа командных строк, которые вы передаете, похоже, есть проблема с «|» символы. Это патч, который я придумал: (в functions / support / env.rb)

require 'aruba/cucumber'
require 'shellwords'

# Here we monkey patch Aruba to work with pipe commands
module Aruba
  class Process
    include Shellwords

    def initialize(cmd, exit_timeout, io_wait)
      @exit_timeout = exit_timeout
      @io_wait = io_wait

      @out = Tempfile.new("aruba-out")
      @err = Tempfile.new("aruba-err")
      @process = ChildProcess.build(cmd)
      @process.io.stdout = @out
      @process.io.stderr = @err
      @process.duplex = true
    end
  end
end

После этого должен работать обычный запуск огурца (Примечание: используйте последнюю версию огурца 1.1.x)

Автоматизация с помощью Rake

Последняя часть автоматизирует это для Vagrant. Для этого мы создаем небольшое задание по рейку:

require "cucumber/rake/task"
task :default => ["validate"]

# Usage rake validate
# - single vm: rake validate
# - multi vm: rake validate vm=logger
Cucumber::Rake::Task.new(:validate) do |task|
    # VM needs to be running already
    vm_name=ENV['vm'] || ""
    ssh_name=ENV['vm'] || "default"
    ENV['SYSTEM_CONNECT']="vagrant ssh #{vm_name}"
    ENV['SYSTEM_EXECUTE']="vagrant ssh_config #{vm_name}| ssh -q -F /dev/stdin #{ssh_name}"
    task.cucumber_opts = ["-s","-c", "features" ]
end

Заключительные слова

Решение позволяет повторно использовать этапы выполнения команды для их локального выполнения, через ssh или какую-либо другую команду подключения.

  • Это работает только для команд, которые работают через ssh, но я думаю, что это уже достаточно для этого. Если бы потребовалось тестирование amqp, вы могли бы также найти проверку команды.
  • Экранирование оболочки некорректно на 100%, для работы со специальными символами или кавычками внутри кавычек требуется больше работы.
  • При тестировании я иногда пропускаю контекст создания сервера (например, параметры, передаваемые в манифест марионетки, или факты), возможно, я мог бы это сделать в манифесте марионетки. Не уверен в этом
  • Если есть интерес, я мог бы превратить это в бродячий плагин, чтобы сделать его действительно легким.

Весь код можно найти в демонстрационном проекте: https://github.com/jedi4ever/vagrant-guard-demo

Источник: http://www.jedi.be/blog/2011/12/15/bdd-testing-with -vagrant /

36
Share: