tapout 0.1.0 → 0.2.0

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/NOTICE.rdoc DELETED
@@ -1,38 +0,0 @@
1
- = COPYRIGHT NOTICES
2
-
3
- == KO
4
-
5
- Copyright (c) 2010 Thomas Sawyer
6
-
7
- Licensed under the Apache License, Version 2.0 (the "License");
8
- you may not use this file except in compliance with the License.
9
- You may obtain a copy of the License at
10
-
11
- http://www.apache.org/licenses/LICENSE-2.0
12
-
13
- Unless required by applicable law or agreed to in writing, software
14
- distributed under the License is distributed on an "AS IS" BASIS,
15
- WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
16
- See the License for the specific language governing permissions and
17
- limitations under the License.
18
-
19
-
20
- == Detest
21
-
22
- A small segement of code for outputing error messages was borrowed from the
23
- Detest[http://snk.tuxfamily.org/lib/detest/] project.
24
-
25
- Copyright 2009 Suraj N. Kurapati <sunaku@gmail.com>
26
-
27
- Permission to use, copy, modify, and/or distribute this software for any
28
- purpose with or without fee is hereby granted, provided that the above
29
- copyright notice and this permission notice appear in all copies.
30
-
31
- THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
32
- WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
33
- MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
34
- ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
35
- WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
36
- ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
37
- OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
38
-
data/TAP-YJ.rdoc DELETED
@@ -1,296 +0,0 @@
1
- = TAP-Y/J Format
2
-
3
- TAP-Y and TAP-J are test streams. They are essentially the same except
4
- for the underlying format used, which are YAML and JSON repsectively.
5
-
6
- == TAP-Y Structure
7
-
8
- TAP-Y is a plain YAML stream format. Only YAML core types are used,
9
- scalar, sequence and mapping.
10
-
11
- A YAML stream is composed a sequence of YAML *documents*, each divided by
12
- a start document marker (<code>---</code>). Each document MUST have a +type+
13
- field which designates it a +header+, +case+, +test+, +note+ or +footer+. Any
14
- document MAY have an +extra+ field which contains an open mapping for
15
- extraneous information.
16
-
17
- === Header
18
-
19
- A +header+ starts a stream of tests.
20
-
21
- ---
22
- type: header
23
- start: 2011-10-10 12:12:32
24
- count: 2
25
- range: 1..2
26
-
27
- The header +count+ indicates the number of total tests forethcoming. If
28
- the number of tests is unknow, count can be omitted or marked <code>~</code>.
29
-
30
- The +range+ defines the index of tests to be run separated by two period marks.
31
- The range will usually start with 1, but may start with another number if the
32
- underlying test system index tests.
33
-
34
- The +start+ entry marks the date and time testing began.
35
-
36
- === Case
37
-
38
- The +case+ type indicates the start of a test case.
39
-
40
- ---
41
- type: case
42
- description: Subtraction
43
-
44
- The case docoument has a +description+ that is a free-form string describing
45
- the nature of the test case.
46
-
47
- === Test
48
-
49
- The +test+ type indicates a test. A test MUST have a +status+ with
50
- one of five possible values: +pass+, +fail+, +error+, +omit+, +pending+.
51
-
52
- ---
53
- type: test
54
- status: pass
55
- description: an important test
56
- file: foo.rb
57
- line: 45
58
- returned: true
59
- expected: true
60
- source: ok 1, 2
61
- snippet:
62
- - 44: ok 0,0
63
- - 45: ok 1,2
64
- - 46: ok 2,4
65
- time: 0.01
66
-
67
- Like a case, the test can have a +description+.
68
-
69
- A test SHOULD also have a +file+ and +line+ number for the location of
70
- of the definition of the test, when +pass+ or +omit+, or the location
71
- of the exception when +fail+ or +error+. A +pending+ test will give the
72
- location of one or the other depending on how the underlying test system
73
- behaves.
74
-
75
- If a test fails or errors it MUST also provide a +message+ describing the
76
- nature of the exception. It MAY also provide a system +backtrace+.
77
-
78
- A test SHOULD also give an +expected+ and +returned+ value, if relavent
79
- to the nature of the test. For example, the most common test operation is
80
- equality, e.g. <code>assert_equal(4,3)</code>, so +expected+ would be 3 and
81
- +returned+ 4.
82
-
83
- A test SHOULD provide the line of +source+ code that triggers the test.
84
- This will be the line of code the +file+ and +line+ number references.
85
-
86
- The +snippet+ is like +source+ but provides surronding context. It MAY be
87
- a verbatim string, in which case it MUST have an odd number of lines with
88
- the source line in the center. Or, it MAY be an ordered map of
89
- <i>- line: source</i>. Using an ordered map the line numbers may start
90
- and end wherever, but they MUST be consecutive and the source line MUST
91
- be among them.
92
-
93
- Lastly, the +time+ is the number of seconds that have elapsed since the
94
- the header start time.
95
-
96
- === Footer
97
-
98
- The +footer+ type incidates the end of a test set.
99
-
100
- ---
101
- type: footer
102
- count: 2
103
- tally:
104
- pass: 1
105
- fail: 1
106
- error: 0
107
- omit: 0
108
- pending: 0
109
- time: 0.03
110
- ...
111
-
112
- It MUST give the total test +count+ and +tally+ for each test status, and
113
- SHOULD give the time ellapsed.
114
-
115
- The test stream end when a full ellipsis (<code>...</code>) appears.
116
-
117
- As you can see TAP-Y streams provide a great deal of detail. They are not
118
- intended for the end-user, but rather to pipe to consuming apps to process
119
- into a human readable form.
120
-
121
-
122
- == TAP-J
123
-
124
- TAP-J documents follows all the same feild rules as TAP-Y, but are represented
125
- as a stream of JSON documents.
126
-
127
- {"type":"header", "count":"2", "range":"1..2"}
128
- {"type":"case", "description":"Subtraction"}
129
- {"type": "test", "status": "pass", "file": "foo.rb", "line": "45", "description": "an important test", "returned": true, "expected": true, "source": "ok 1, 2", "snippet": [{44:" ok 0,0"},{45:" ok 1,2"},{46:" ok 2,4"}], "time": 0.01}
130
-
131
- ...
132
-
133
- Ans so on.
134
-
135
-
136
- == Glossery of Fields
137
-
138
- === count
139
-
140
- The `count` field provides the total number of tests being executed. It SHOULD
141
- be given in the header, if possible, and it MUST be given in the footer.
142
-
143
- === extra
144
-
145
- Additional data, not specifucally designated by this sepecification can
146
- place under the `extra` section without worry that future versions of the
147
- specification will come into conflict with the field name. The namespace
148
- is a free-for-all, so use it with that in mind. Teh `extra` field can
149
- appear in any document.
150
-
151
- === file
152
-
153
- The `file` field provides the name of the file in which the test is defined,
154
- or where th test failed/errored.
155
-
156
- === line
157
-
158
- The `line` field provides the line number of the file on which the
159
- definition of the test begins, or is the line number of where the
160
- test failed/errored.
161
-
162
- === message
163
-
164
- For tests with `fail` or `error` status, the message provides the explination
165
- for the failure or error. Usually this is just the error message produced by
166
- the underlying exception. The `pass` type can have the message field too,
167
- but it will generally be ignored by TAP consumers.
168
-
169
- === range
170
-
171
- The range of tests being executed of the test suite. The range is written in
172
- the form of `X..Y`. Where X is the index of the first test and Y is the index
173
- of last test.
174
-
175
- NOTE: This may be deprecated since the count field probably suffices. Can a
176
- range uniquely identify the tests being run? If not, the first sentinal will
177
- always be 1, which is redundant.
178
-
179
- === snippet
180
-
181
- The `snippet` field is either a verbatim string or an ordered mapping of line
182
- number mapped to the source code for that line. While `snippet` is
183
- like `source` it also contains extra lines of code before and after the
184
- test `line` for context.
185
-
186
- If `snippet` is a string it MUST consist an odd number of lines, the same
187
- number before and after the source line in the center, unless the line occurs
188
- at the begining or the end of the file. The number of lines before and after is
189
- arbitrary and up to the producer, but should be the same on either side. Three
190
- to five is generally enough.
191
-
192
- === source
193
-
194
- The `source` field is a verbatim copy of the source code that defines the test.
195
- This may be just the first line of the definition. In classic TAP this
196
- is called `raw_test`.
197
-
198
- === start
199
-
200
- The header SHOULD have a start time in ISO standard format <code>YYYY-MM-DD HH:MM:SS</code>.
201
-
202
- === status
203
-
204
- The `status` field designates the status of a test document. Valid values
205
- are `pass`, `fail`, `error`, `omit` and `pending`.
206
-
207
- In comparison to the classic TAP format, `pass` is equivalent to `ok` and
208
- `fail` and `error` are akin to `not ok`, where `fail` is "not ok" with regards
209
- to a test assertion and `error` is "not ok" becuase of a raised coding error.
210
-
211
- Tests with an `omit` status do not need to be provided in the document stream,
212
- so this status will rarely appear in practice. But if a producer chooses to do
213
- so this status simply means the test is purposefully being disregarded.
214
-
215
- On the other hand, `pending` means the test will be used in the future
216
- but implementation has not been completed. It serves as reminder to developers
217
- to write a missing test.
218
-
219
- === tally
220
-
221
- The footer MUST provide a tally for all status categories. This is like `count`
222
- but broken down into status groups.
223
-
224
- === time
225
-
226
- The tests and the footer SHOULD have the +time+ elapsed since starting the
227
- tests given in number of seconds.
228
-
229
- === type
230
-
231
- Each document MUST have a *type*. Valid types are `header`, `footer`, `case`,
232
- `test` and `note`.
233
-
234
- The `header` and `footer` types can only occur once, at the start and end of the
235
- stream, respectively. All other types may occur repeatedly in between.
236
-
237
- The `case` type marks the start of a testcase. All `test` (and `note`)
238
- documents following it are considered a part of the case until a new case
239
- document occurs.
240
-
241
-
242
- == Example - Complete TAP-Y Stream
243
-
244
- Here is a complete example.
245
-
246
- An example of a TAP-Y stream looks like this:
247
-
248
- ---
249
- type: header
250
- count: 2
251
- range: 1..2
252
- ---
253
- type: case
254
- description: Subtraction
255
- ---
256
- type: test
257
- status: pass
258
- file: foo.rb
259
- line: 45
260
- description: an important test
261
- returned: true
262
- expected: true
263
- source: ok 1, 2
264
- snippet:
265
- - 44: ok 0,0
266
- - 45: ok 1,2
267
- - 46: ok 2,4
268
- ---
269
- type: test
270
- status: fail
271
- file: foo.rb
272
- line: 46
273
- description: another test
274
- returned: false
275
- expected: true
276
- source: ok 2,4
277
- snippet:
278
- - 45: ok 1,2
279
- - 46: ok 2,4
280
- - 47:
281
- message:
282
- blah blah
283
- extra:
284
- THAC0: 16
285
- ---
286
- type: footer
287
- time: 0.01
288
- count: 2
289
- tally:
290
- pass: 1
291
- fail: 1
292
- error: 0
293
- omit: 0
294
- pending: 0
295
- ...
296
-