auxesis-cucumber-nagios 0.3.4 → 0.3.5
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- data/README.md +1 -1
- data/lib/generators/project/README +138 -30
- metadata +1 -1
data/README.md
CHANGED
|
@@ -1,54 +1,162 @@
|
|
|
1
|
-
|
|
2
|
-
|
|
1
|
+
What do I do now?
|
|
2
|
+
=================
|
|
3
3
|
|
|
4
|
-
|
|
5
|
-
|
|
4
|
+
1. freeze your project
|
|
5
|
+
2. version control your project
|
|
6
|
+
3. write features
|
|
6
7
|
|
|
7
8
|
|
|
8
|
-
Freezing
|
|
9
|
+
Freezing
|
|
9
10
|
========
|
|
10
11
|
|
|
11
|
-
Freezing your dependencies allows you to drop your
|
|
12
|
-
any machine and have it run. Its only requirement is
|
|
12
|
+
Freezing your dependencies into your project allows you to drop your
|
|
13
|
+
cucumber-nagios project to any machine and have it run. Its only requirement is
|
|
14
|
+
Ruby and Rake.
|
|
13
15
|
|
|
14
|
-
To freeze your project, run:
|
|
16
|
+
To freeze your project, within your project directory run:
|
|
15
17
|
|
|
16
|
-
|
|
18
|
+
$ rake deps
|
|
17
19
|
|
|
18
20
|
|
|
19
|
-
|
|
20
|
-
|
|
21
|
+
Version control
|
|
22
|
+
===============
|
|
21
23
|
|
|
22
|
-
|
|
24
|
+
I highly recommend storing your cucumber-nagios projects in a version control
|
|
25
|
+
system!
|
|
26
|
+
|
|
27
|
+
To get up and running with git:
|
|
28
|
+
|
|
29
|
+
$ git init
|
|
30
|
+
$ git add .
|
|
31
|
+
$ git commit -m 'created cucumber-nagios project'
|
|
32
|
+
|
|
33
|
+
To get up and running with bzr:
|
|
34
|
+
|
|
35
|
+
$ bzr init
|
|
36
|
+
$ bzr add
|
|
37
|
+
$ bzr commit -m 'created cucumber-nagios project'
|
|
38
|
+
|
|
39
|
+
.bzrignore and .gitignores are created when you generate a project.
|
|
23
40
|
|
|
24
|
-
$ rake deps
|
|
25
41
|
|
|
26
42
|
Writing features
|
|
27
43
|
================
|
|
28
44
|
|
|
29
|
-
|
|
30
|
-
|
|
31
|
-
feature you're testing:
|
|
45
|
+
You can use the bin/cucumber-nagios-gen command to generate new features for
|
|
46
|
+
you. It takes two arguments: the site you're testing, and feature you're testing:
|
|
32
47
|
|
|
33
|
-
|
|
48
|
+
bin/cucumber-nagios-gen feature gnome.org navigation
|
|
34
49
|
|
|
50
|
+
This will spit out two files:
|
|
35
51
|
|
|
36
|
-
|
|
37
|
-
|
|
52
|
+
features/gnome.org/navigation.feature
|
|
53
|
+
features/gnome.org/steps/navigation_steps.rb
|
|
38
54
|
|
|
39
|
-
I highly recommend storing your cucumber-nagios features in a version control
|
|
40
|
-
system!
|
|
41
55
|
|
|
42
|
-
|
|
56
|
+
As for writing features, you'll want to have a read of the Cucumber
|
|
57
|
+
documentation[0], however your tests will look something like this:
|
|
43
58
|
|
|
44
|
-
|
|
45
|
-
|
|
46
|
-
|
|
59
|
+
Feature: google.com.au
|
|
60
|
+
It should be up
|
|
61
|
+
And I should be able to search for things
|
|
62
|
+
|
|
63
|
+
Scenario: Searching for things
|
|
64
|
+
Given I visit "http://www.google.com"
|
|
65
|
+
When I fill in "q" with "wikipedia"
|
|
66
|
+
And I press "Google Search"
|
|
67
|
+
Then I should see "www.wikipedia.org"
|
|
47
68
|
|
|
48
|
-
To get up and running with bzr:
|
|
49
69
|
|
|
50
|
-
|
|
51
|
-
|
|
52
|
-
|
|
70
|
+
There's a collection of steps that will cover most of the things you'll be
|
|
71
|
+
testing for in features/steps/webrat_steps.rb.
|
|
72
|
+
|
|
73
|
+
You can write custom steps for testing specific output and behaviour, e.g.
|
|
74
|
+
in features/smh.com.au/smh.feature:
|
|
75
|
+
|
|
76
|
+
Feature: smh.com.au
|
|
77
|
+
It should be up
|
|
78
|
+
And provide links to content
|
|
79
|
+
|
|
80
|
+
Scenario: Visiting home page
|
|
81
|
+
When I go to http://smh.com.au/
|
|
82
|
+
Then I should see site navigation
|
|
83
|
+
And there should be a section named "Opinion"
|
|
84
|
+
|
|
85
|
+
There aren't steps for "Then I should see site navigation", so you have to
|
|
86
|
+
write one yourself. :-) In features/smh.com.au/steps/smh_steps.rb:
|
|
87
|
+
|
|
88
|
+
Then /^I should see site navigation$/ do
|
|
89
|
+
doc = Nokogiri::HTML(response.body.to_s)
|
|
90
|
+
doc.css("ul#nav li a").size.should > 5
|
|
91
|
+
end
|
|
92
|
+
|
|
93
|
+
You can use Nokogiri for testing responses with XPath matchers and CSS
|
|
94
|
+
selectors.
|
|
95
|
+
|
|
96
|
+
I suggest you use bin/cucumber directly so you can get better feedback when
|
|
97
|
+
writing your tests:
|
|
98
|
+
|
|
99
|
+
bin/cucumber --require bin/common.rb \
|
|
100
|
+
--require features/
|
|
101
|
+
features/smh/smh.feature
|
|
102
|
+
|
|
103
|
+
This will output using the default 'pretty' formatter.
|
|
104
|
+
|
|
105
|
+
Running
|
|
106
|
+
=======
|
|
107
|
+
|
|
108
|
+
Invoke the Cucumber feature with the cucumber-nagios script:
|
|
109
|
+
|
|
110
|
+
bin/cucumber-nagios features/smh.com.au/smh.feature
|
|
111
|
+
|
|
112
|
+
cucumber-nagios can be run from anywhere:
|
|
113
|
+
|
|
114
|
+
/path/to/bin/cucumber-nagios /path/to/features/smh/smh.feature
|
|
115
|
+
|
|
116
|
+
It should return a standard Nagios-formatted response string:
|
|
117
|
+
|
|
118
|
+
Critical: 0, Warning: 0, 2 okay | passed=2, failed=0, total=2
|
|
119
|
+
|
|
120
|
+
Steps that fail will show up in the "Critical" total, and steps that pass
|
|
121
|
+
show up in the "okay" total.
|
|
122
|
+
|
|
123
|
+
The value printed at the end is in Nagios's Performance Data format, so it
|
|
124
|
+
can be graphed and the like.
|
|
125
|
+
|
|
126
|
+
|
|
127
|
+
Quirks & Caveats
|
|
128
|
+
================
|
|
129
|
+
|
|
130
|
+
Multiple scenarios
|
|
131
|
+
------------------
|
|
132
|
+
|
|
133
|
+
You may want to think about keeping to one scenario to a file, otherwise
|
|
134
|
+
you'll get multiple lines of output for a test:
|
|
135
|
+
|
|
136
|
+
Critical: 1, Warning: 0, 2 okay | passed=2, failed=1, total=3
|
|
137
|
+
Critical: 1, Warning: 0, 4 okay | passed=4, failed=1, total=5
|
|
138
|
+
|
|
139
|
+
That said, Nagios should only read the last line, so this might be an ok
|
|
140
|
+
behaviour when you want to test for an aggregate of failures across a site.
|
|
141
|
+
|
|
142
|
+
|
|
143
|
+
Failure *is* an option (exceptions are good)
|
|
144
|
+
--------------------------------------------
|
|
145
|
+
|
|
146
|
+
Exceptions raised within your tests will appear in the failed totals, so you
|
|
147
|
+
don't need to worry about trying to catch them in your own custom steps.
|
|
148
|
+
|
|
149
|
+
i.e. if you try fetching a page on a server that is down, or the page returns
|
|
150
|
+
a 404, the exception raised by Mechanize just gets treated by Cucumber as a
|
|
151
|
+
test failure.
|
|
152
|
+
|
|
153
|
+
|
|
154
|
+
Redeploying
|
|
155
|
+
===========
|
|
156
|
+
|
|
157
|
+
Once you've copied your project around, Just run the freezer again:
|
|
158
|
+
|
|
159
|
+
$ rake deps
|
|
160
|
+
|
|
53
161
|
|
|
54
|
-
|
|
162
|
+
[0] http://wiki.github.com/aslakhellesoy/cucumber
|