This repository has been archived by the owner on Dec 3, 2018. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 0
/
README
113 lines (84 loc) · 3.9 KB
/
README
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
= An Experiment
First let me say up front that this library is an experiment. I don't
even know if it is a good idea yet but if you are feeling adventurous
I encourage you to take the red pill and see how deep this rabbit hole
goes.
= Putting Tests In-line
So the basic goal of this library is to allow you put your test right
next to the code being tested. For example:
def multiply(a, b)
a * b
end
Test do
assert_equal 6, multiply(2, 3)
assert_equal 10, multiply(5, 10)
assert_not_equal 42, multiply(6, 9)
end
Lets go over a few of the key features of in-line testing.
== Optional Naming
The name of a test is often used just to know what code it is testing.
For example under traditional Test::Unit I might call the test
"test_multiply". But this name is entirely redundant when you start
placing your tests next to the code being tested. It is obvious what is
being testing. When a tests fails we are often just looking at the line
number so naming the test doesn't really help there.
This doesn't mean I am against naming test. For example you may have
multiple test blocks that are testing a single method. You want them
in multiple blocks because each has a specific purpose. So you may
want to give them a name to let others know of that purpose. For
example we might write the above as:
def multiply(a, b)
a * b
end
Test 'success' do
assert_equal 6, multiply(2, 3)
assert_equal 10, multiply(5, 10)
end
Test 'failure' do
assert_not_equal 42, multiply(6, 9)
end
Here we have separated our success testing and our failure testing into
separate test blocks. But even here the name is just a label. In fact
we may later have another set of tests that have a "success" and
"failure" block. This is allowed (multiple test blocks can have the
same label).
== Test By Running
Another advantage to having tests and code together is that you can
test a file just by running it (assuming the code is written to be
fairly independent). No need to have fancy rake tasks or test suites.
Just execute the file you are currently coding and the results are
returned to you.
Of course you can still run a test suite of your entire project if you
want but sometimes it is nice to be able to pass around a file that
contains the documentation, the code and the test all together and you
can just run it to verify it is working.
== Rails integration
We also provide Rails integration. Simply include this gem in your Rails
project and add the following lines to your Rakefile:
require 'test_inline'
require 'test_inline/rails_tasks'
Now you will be able to run your unit tests with a simple:
rake test:inline:units
You will be able to run your functional test with:
rake test:inline:functionals
Or you can run both with just:
rake test:inline
Finally note that our Rails integration will make the TestCase inherit
from the right classes in the Rails framework. So for example
you can just call the normal "get, post, etc" methods in your controller
tests, you can access the Rails specific assertions (such as
assert_redirected_to). You can just place your tests right in with the
controllers, helpers and models and it will do the right thing.
== Wrapper for Test::Unit
We are currently just wrapping Test::Unit. This has the advantage of
building on something well used and standard in the Ruby world. It means
that any traditional Test::Unit can be converted over to test_inline
mostly by just copying and pasting. This does cause problems in the fact
that Test::Unit has certain concepts that we don't use (like named test
cases and named test methods). For test cases we just generate anonymous
classes. For test methods we generate unique name (possibly based on the
optional label).
This of course opens up the question of would it be a good idea to allow
wrapping of other test environments like RSpec, Cucumber, etc. Those
questions are left to others as Test::Unit is good enough for most
Ruby projects.