Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP
Browse files

Prettify README with some syntax highlighting

  • Loading branch information...
commit 20cfb2d7c0b96440a158a9ed45aafdb9504e3c14 1 parent 77307cb
@rodjek authored
Showing with 52 additions and 25 deletions.
  1. +52 −25 README.md
View
77 README.md
@@ -33,13 +33,15 @@ If you use the above directory structure, your examples will automatically be
placed in the correct groups and have access to the custom matchers. If you
choose not to, you can force the examples into the required groups as follows.
- describe 'myclass', :type => :class do
- ...
- end
+```ruby
+describe 'myclass', :type => :class do
+ ...
+end
- describe 'mydefine', :type => :define do
- ...
- end
+describe 'mydefine', :type => :define do
+ ...
+end
+```
## Matchers
@@ -49,21 +51,32 @@ You can test if a class has been included in the catalogue with the
`include_class` matcher. It takes the class name as a string as its only
argument
- it { should include_class('foo') }
+```ruby
+it { should include_class('foo') }
+```
### Checking if a resources exists
You can test if a resource exists in the catalogue with the generic
-`creates_<resource type>` matcher. If your resource type includes :: (e.g.
+`contain_<resource type>` matcher.
+
+```ruby
+it { should contain_augeas('bleh') }
+```
+
+If your resource type includes :: (e.g.
`foo::bar` simply replace the :: with __ (two underscores).
- it { should contain_augeas('bleh') }
- it { should contain_foo__bar('baz') }
+```ruby
+it { should contain_foo__bar('baz') }
+```
You can further test the parameters that have been passed to the resources with
the generic `with_<parameter>` chains.
- it { should contain_package('mysql-server').with_ensure('present') }
+```ruby
+it { should contain_package('mysql-server').with_ensure('present') }
+```
## Writing tests
@@ -81,46 +94,60 @@ Will cause the following resource to be in included in catalogue for a host
command => '/sbin/sysctl -p /etc/sysctl.conf',
}
-We can write the following testcase
+We can write the following testcase (in `spec/defines/sysctl_spec.rb`)
- describe 'sysctl' do
- let(:title) { 'baz' }
- let(:params) { { :value => 'foo' } }
+```ruby
+describe 'sysctl' do
+ let(:title) { 'baz' }
+ let(:params) { { :value => 'foo' } }
- it { should contain_exec('sysctl/reload').with_command("/sbin/sysctl -p /etc/sysctl.conf") }
- end
+ it { should contain_exec('sysctl/reload').with_command("/sbin/sysctl -p /etc/sysctl.conf") }
+end
+```
### Specifying the title of a resource
- let(:title) { 'foo' }
+```ruby
+let(:title) { 'foo' }
+```
### Specifying the parameters to pass to a resources or parametised class
- let(:params) { {:ensure => 'present', ...} }
+```ruby
+let(:params) { {:ensure => 'present', ...} }
+```
### Specifying the FQDN of the test node
If the manifest you're testing expects to run on host with a particular name,
you can specify this as follows
- let(:node) { 'testhost.example.com' }
+```ruby
+let(:node) { 'testhost.example.com' }
+```
### Specifying the facts that should be available to your manifest
By default, the test environment contains no facts for your manifest to use.
You can set them with a hash
- let(:facts) { {:operatingsystem => 'Debian', :kernel => 'Linux', ...} }
+```ruby
+let(:facts) { {:operatingsystem => 'Debian', :kernel => 'Linux', ...} }
+```
### Specifying the path to find your modules
I recommend setting a default module path by adding the following code to your
`spec_helper.rb`
- RSpec.configure do |c|
- c.module_path = '/path/to/your/module/dir'
- end
+```ruby
+RSpec.configure do |c|
+ c.module_path = '/path/to/your/module/dir'
+end
+```
However, if you want to specify it in each example, you can do so
- let(:module_path) { '/path/to/your/module/dir' }
+```ruby
+let(:module_path) { '/path/to/your/module/dir' }
+```
Please sign in to comment.
Something went wrong with that request. Please try again.