File: README.rdoc

package info (click to toggle)
ruby-shindo 0.3.8-2
  • links: PTS, VCS
  • area: main
  • in suites: bullseye, buster, sid
  • size: 204 kB
  • sloc: ruby: 457; makefile: 13
file content (140 lines) | stat: -rw-r--r-- 4,412 bytes parent folder | download | duplicates (2)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
= shindo

Simple depth first ruby testing, watch and learn.

== Writing tests

Tests group similar assertions, but their return value is ignored.

After that you just test based on the two things a ruby thing should do, raise or return.

Returns takes what you expect and checks a block to see if the return value matches:

  Shindo.tests do
    returns(true) { true }
    returns(false) { false }
  end

Raises takes what error you expect and checks to see if the block will raise it:

  Shindo.tests do
    raises(StandardError) { raise StandardError.new }
  end

For one off simple tests like this you can also chain the calls like this:

  Shindo.tests('raises').raises(StandardError) { raise StandardError.new }

You can also override the default descriptions:

  Shindo.tests('foo/bar') do
    returns('foo', 'returns foo when bar') { 'foo' }
    raises(StandardError, 'raises StandardError when baz') { raise StandardError }
  end

Or nest things inside tests blocks:
  Shindo.tests do
    tests('returns') do
      returns('foo', 'returns foo when bar') { 'foo' }
      returns('bar', 'returns bar when baz') { 'bar' }
    end
    tests('raises') do
      raises(StandardError, 'raises StandardError when baz') { raise StandardError }
      raises(StandardError, 'raises StandardError when qux') { raise StandardError }
    end
  end

Then, if you want to get real fancy you can also tag your tests, to help narrow down which ones to run

  Shindo.tests('tests for foo', 'foo') do
    test('foo') { true }
  end

  Shindo.tests('tests for bar', 'bar') do
    test('bar') { true }
  end

Note: you'll have to supply a non-default description first, and then follow up with tags.

== Setup and Teardown

Tests get evaluated in the file just like you see it so you can add setup and teardown easily:

  Shindo.tests do
    foo = 'bar' # setup
    tests('foo').returns('bar') { foo }

    foo = 'baz' # cleanup after last
    tests('foo').returns('baz') { foo }

    foo = nil # teardown
  end

That can get pretty tedious if it needs to happen before or after every single test though, so there are helpers:

  Shindo.tests do
    before do
      @object = Object.new
    end

    after do
      @object = nil
    end

    tests('@object.class').returns(Object) { @object.class }
  end

== Running tests

Run tests with the shindo command, the easiest is to specify a file name:

  shindo something_tests.rb

You can also give directories and it will run all files ending in _tests.rb and include all files ending in _helper.rb (recurses through subdirectories)

  shindo some_test_directory

That leaves tags, which use +/-.  So run just tests with the 'foo' tag:

  shindo some_test_directory +foo

Or those without the 'bar' tag:

  shindo some_test_directory -bar

Or combine to run everything with a foo tag, but no bar tag

  shindo some_test_directory +foo -bar

If you are running in a non-interactive mode, or one where speed matters (i.e. continuous integration), you can run shindo with (n)o (t)race and much quieter output. It takes all the same arguments, but uses the shindont bin file.

  shindont something_tests.rb

== Command line tools

When tests fail you'll get lots of options to help you debug the problem, just enter '?' at the prompt to see your options.

== Copyright

(The MIT License)

Copyright (c) 2009 {geemus (Wesley Beary)}[http://github.com/geemus]

Permission is hereby granted, free of charge, to any person obtaining
a copy of this software and associated documentation files (the
"Software"), to deal in the Software without restriction, including
without limitation the rights to use, copy, modify, merge, publish,
distribute, sublicense, and/or sell copies of the Software, and to
permit persons to whom the Software is furnished to do so, subject to
the following conditions:

The above copyright notice and this permission notice shall be
included in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE
LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION
OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION
WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.