1

I am writing a simple cookbook that will be used to deploy an SSL proxy onto a server. This cookbook will ultimately be used by other cookbooks that deploy web services in order to set up an SSL proxy in front of them, but for the purpose of testing the proxy cookbook itself, there is no such service behind it. My basic testing strategy for this cookbook is as follows:

  1. Converge the box with test-kitchen
  2. Use ServerSpec (or possibly Bats) with test-kitchen to
    1. Setup test by starting a python SimpleHTTPServer on the box listing on the port that the proxy was configured to forward to, and create in index.html file for it to serve.
    2. Assert that when I hit https://localhost I get the file that SimpleHTTPServer is serving.
    3. Assert a few more things about the proxy (all of which require that there be a service behind it.)
  3. Teardown. No real need to tear anything down, just let test-kitchen destroy the box.

So my question is, what is the right way to set up these sort of test preconditions using test-kitchen and ServerSpec and/or bats?

Kenneth Baltrinic
  • 2,941
  • 2
  • 28
  • 45
  • So I have discovered that Bats supports setup and teardown methods because it is not chef-specific. But bats is a bit limitted for cross platform tests. Still looking to see if there a way to get this functionality in ServerSpec. – Kenneth Baltrinic Mar 17 '15 at 16:08

2 Answers2

0

If the setup and teardown truly aren't part of what I'm testing, then I usually just do them in Ruby somewhere that runs before each test (often, in spec_helper.rb). Since serverspec is just literally running ruby code line by line on a test-kitchen instance, it doesn't feel necessary to me to have something in serverspec that offers setup/teardown functionality (in other words, there's no ordering issues or repeated tests that would require calling a setup or teardown method).

Martin
  • 2,815
  • 1
  • 21
  • 30
  • Pardon if this is an ignorant question, but I am no ruby guru and relatively new to the who chef ecosystem. That said, will this approach work for guaranteed teardown, or do I have to place all of my tests in a rescue block to ensure teardown? (I am finding that I do need teardown vs relying on kitchen destroy, if I want to rerun tests during dev w/o having to completely recreate my VMs). – Kenneth Baltrinic Mar 18 '15 at 17:22
  • The usual advice is to completely destroy and re-create the VMs for a clean test. I usually get the tests passing using `kitchen converge` and `kitchen verify`, and then do a full `kitchen test` to be sure once I have no more changes. Is there a reason you can't do the cleanup of old state and re-setup in one setup step? – Martin Mar 19 '15 at 01:33
  • Yes that is what I am doing as well. So in simple cases, putting the cleanup at the top of the setup might work but I can see more complex cases with multiple specs having conflicting setup needs. I don't want each spec to have to know how to teardown every other spec. Best if each handles its own. – Kenneth Baltrinic Mar 19 '15 at 11:55
  • If the specs have some state that is hard to clean up, I'd recommend separate test suites. Starting from a clean slate is hard to guarantee even if the test framework did provide a teardown step. – Martin Mar 21 '15 at 15:09
0

Old question, but for completeness:
You can use rspec's before in serverspec.

describe file('/tmp/testfile') do
  before do
    File.write('/tmp/testfile', 'Hello, world')
  end
  it { should exist }
  its(:content) { should include('Hello') }
end

The http_get type from https://github.com/jantman/serverspec-extended-types may provide whats needed for HTTP server testing from within serverspec.

Christo
  • 1