ISpec - Revision history

Bguthrie: /* Defining a custom assertion */

2009-05-03T02:36:34Z

‎Defining a custom assertion

Bguthrie at 02:35, 3 May 2009

2009-05-03T02:35:56Z

Bguthrie: /* Defining a custom assertion */

2009-05-03T02:32:18Z

‎Defining a custom assertion

Bguthrie: /* Running an ISpec file */

2009-05-02T16:04:25Z

‎Running an ISpec file

Bguthrie at 16:03, 2 May 2009

2009-05-02T16:03:18Z

Bguthrie at 23:51, 30 April 2009

2009-04-30T23:51:51Z

Bguthrie at 17:34, 30 April 2009

2009-04-30T17:34:21Z

Olabini at 08:26, 26 January 2009

2009-01-26T08:26:47Z

Cv at 00:38, 26 January 2009

2009-01-26T00:38:21Z

Cv: New page: ISpec is a minimal port of the Ruby RSpec framework for behavior-driven development. It supports the bare minimum to allow testing of Ioke itself. The current Ioke test suite is completely...

2009-01-26T00:37:37Z

New page: ISpec is a minimal port of the Ruby RSpec framework for behavior-driven development. It supports the bare minimum to allow testing of Ioke itself. The current Ioke test suite is completely...

New page

ISpec is a minimal port of the Ruby RSpec framework for behavior-driven development. It supports the bare minimum to allow testing of Ioke itself. The current Ioke test suite is completely written in ISpec, and it seems to be a capable environment.

The ispec command line tool takes one argument -- "-f" to specify which format to print in. The default is "p" for progress, which only shows one dot for each test run. The "s" alternative shows the longer spec format. To run all tests in a directory with spec format:

<pre>ispec -fs test_dir</pre>
This command will find all files ending in _spec.ik and run the specs defined in them. If a single file is specified, only the tests in that file will run. If more than one directory or file is specified on the command line, all the tests will be run together. Provided the spec files all use the ispec module, the files can be run directly with the ioke-command too.

A full test file utilizing most of the parts of ISpec looks like this:

<pre>use("ispec")

describe(Foo,
it("should have the correct kind",
Foo should have kind("Foo")
Foo kind should == "Foo"
Foo kind should match(#/Fo+/)
)

it("should be possible to mimic",
m = Foo mimic
m should have kind("Foo")
m should not be same(Foo)
m should mimic(Foo)
)

describe("aMethod",
it("should not return nil",
Foo aMethod should not be nil
)

it("should return a number that can be multiplied",
(Foo aMethod * 2) should == 12
)
)

describe("aBadMethod",
it("should signal a condition",
fn(Foo aBadMethod) should signal(Condition Error BadBadBed)
)
)
)</pre>
This code first makes sure to use ISpec, then describes Foo. The describe method takes either kinds or texts describing what's under test. This can be nested arbitrarily deep. A test is defined with the "it" method, which takes a text describing the test first, and the implementation of the test as the second argument. If the second argument is left out, the test is considered pending.

Assertions are done using the "should" method. This returns an expectation that can check several different things against the original receiver. Using == is the simplest expectation and checks that a value equals another. By adding the not method call inbetween, the expectation is inversed. There are some predefined expectations. Except for ==, these are mimic, match and signal. The signal expectation makes sure that a condition is signalled in the code. The match expectation will check a text value against a regular expression. The mimic expectation checks whether an object mimics another.

The words "be" and "have" are ignored in the expectations. They are so called fluff words - that are only there to make it more readable.

If an expectation receives a message it doesn't know about, it uses pass to check a dynamic property. For example, something like "foo should be same(x)" will end up calling "same?" with x as an argument. The same thing happens in the above code to check for kind. There exists no kind expectation. Instead the kind checking will go check for "kind?".

@@ Line 97: / Line 97: @@
    ShouldContext mimic = method(value,
    unless(realValue mimics?(value),
-     error!(ISpec ExpectationNotMet, text: "expected #{realValue inspect} to mimic #{value kind}", shouldMessage: self shouldMessage)))
+     error!(ISpec ExpectationNotMet, text: "expected #{realValue inspect} to mimic #{value kind}", shouldMessage: self shouldMessage))
 </source>

← Older revision		Revision as of 02:35, 3 May 2009
Line 92:		Line 92:

	All Ioke assertions are defined as cells on ShouldContext and NotShouldContext. The mimicked context receives a reference to the object you'd like to assert against through the realValue cell. Here's a simple example:		All Ioke assertions are defined as cells on ShouldContext and NotShouldContext. The mimicked context receives a reference to the object you'd like to assert against through the realValue cell. Here's a simple example:
		+
		+	<source lang="ioke">
		+	ISpec do(
		+	ShouldContext mimic = method(value,
		+	unless(realValue mimics?(value),
		+	error!(ISpec ExpectationNotMet, text: "expected #{realValue inspect} to mimic #{value kind}", shouldMessage: self shouldMessage)))
		+	</source>
		+
		+	This allows you to make the following assertion:
		+
		+	<source lang="ioke">
		+	[] should mimic(List)
		+	</source>
		+
		+	Note that ShouldContext must re-map the mimic method to __mimic__ to allow this to occur.
		+
		+	ShouldContext cells can be either methods or macros and can become rather complex. For example, the receive assertion (for constructing mocks) builds messages that get stored on ISpec's StubWrangler for checking after each spec is run.

← Older revision		Revision as of 02:32, 3 May 2009
Line 91:		Line 91:
	== Defining a custom assertion ==		== Defining a custom assertion ==

−	All Ioke assertions are defined as cells on ShouldContext and NotShouldContext. ~~Define~~ a ~~method on both modules~~ to ~~provide each kind of assertion. More info coming later~~.	+	All Ioke assertions are defined as cells on ShouldContext and NotShouldContext. The mimicked context receives a reference to the object you'd like to assert against through the realValue cell. Here's a simple example:

@@ Line 78: / Line 78: @@
 Other options:
-  -f Specify the output format. Currently three formats are supported: s[pecdoc] (textual output with example titles), p[rogress] (one dot output for each test run) and h[tml] for use in continuous integration output and Textmate test runs.
+  -f Specify the output format. Currently three formats are supported:
   -p Limit files loaded to those matching pattern.
   -c Use colored output (default: true).

@@ Line 55: / Line 55: @@
 More complex cases allow you to specify key-value pairs:
-<source lang="ioke">foo should receive(bar: 5, baz(6): 7)</source>
+<source lang="ioke">foo should receive(bar: 5, baz: "qux")</source>
 Finally, you can get arbitrarily complex:

@@ Line 1: / Line 1: @@
 ISpec is a testing framework designed to enable behavior-driven development which takes its inspiration from [http://rspec.info RSpec], a similar Ruby framework. The current Ioke test suite is completely written in ISpec, and it seems to be a capable environment.
 == Usage ==
@@ Line 82: / Line 69: @@
 See the specs for ISpec mocking for more detailed usage examples.

@@ Line 1: / Line 1: @@
-ISpec is a minimal port of the [http://rspec.info Ruby RSpec] framework for behavior-driven development. It supports the bare minimum to allow testing of Ioke itself. The current Ioke test suite is completely written in ISpec, and it seems to be a capable environment.
+ISpec is a testing framework designed to enable behavior-driven development which takes its inspiration from [http://rspec.info RSpec], a similar Ruby framework. The current Ioke test suite is completely written in ISpec, and it seems to be a capable environment.
 <pre>ispec -fs test_dir</pre>
 This command will find all files ending in _spec.ik and run the specs defined in them. If a single file is specified, only the tests in that file will run. If more than one directory or file is specified on the command line, all the tests will be run together. Provided the spec files all use the ispec module, the files can be run directly with the ioke-command too.
 A full test file utilizing most of the parts of ISpec looks like this:
@@ Line 42: / Line 52: @@
 This code first makes sure to use ISpec, then describes Foo. The describe method takes either kinds or texts describing what's under test. This can be nested arbitrarily deep. A test is defined with the &quot;it&quot; method, which takes a text describing the test first, and the implementation of the test as the second argument. If the second argument is left out, the test is considered pending.
-Assertions are done using the &quot;should&quot; method. This returns an expectation that can check several different things against the original receiver. Using == is the simplest expectation and checks that a value equals another. By adding the not method call inbetween, the expectation is inversed. There are some predefined expectations. Except for ==, these are mimic, match and signal. The signal expectation makes sure that a condition is signalled in the code. The match expectation will check a text value against a regular expression. The mimic expectation checks whether an object mimics another.
+Assertions are made using the &quot;should&quot; method. This returns an expectation that can check several different things against the original receiver. Using == is the simplest expectation and checks that a value equals another. By adding the not method call inbetween, the expectation is inversed. There are some predefined expectations. Except for ==, these are mimic, match and signal. The signal expectation makes sure that a condition is signalled in the code. The match expectation will check a text value against a regular expression. The mimic expectation checks whether an object mimics another.
 The words &quot;be&quot; and &quot;have&quot; are ignored in the expectations. They are so called fluff words - that are only there to make it more readable.
 If an expectation receives a message it doesn't know about, it uses pass to check a dynamic property. For example, something like &quot;foo should be same(x)&quot; will end up calling &quot;same?&quot; with x as an argument. The same thing happens in the above code to check for kind. There exists no kind expectation. Instead the kind checking will go check for &quot;kind?&quot;.

@@ Line 8: / Line 8: @@
 A full test file utilizing most of the parts of ISpec looks like this:
-<pre>use(&quot;ispec&quot;)
+<source lang="ioke">use("ispec")
 describe(Foo,
-   it(&quot;should have the correct kind&quot;,
+   it("should have the correct kind",
-     Foo should have kind(&quot;Foo&quot;)
+     Foo should have kind("Foo")
-     Foo kind should == &quot;Foo&quot;
+     Foo kind should == "Foo"
      Foo kind should match(#/Fo+/)
+   )
-   it(&quot;should be possible to mimic&quot;,
+   it("should be possible to mimic",
      m = Foo mimic
-     m should have kind(&quot;Foo&quot;)
+     m should have kind("Foo")
      m should not be same(Foo)
      m should mimic(Foo)
+   )
-   describe(&quot;aMethod&quot;,
+   describe("aMethod",
-     it(&quot;should not return nil&quot;,
+     it("should not return nil",
        Foo aMethod should not be nil
+     )
-     it(&quot;should return a number that can be multiplied&quot;,
+     it("should return a number that can be multiplied",
        (Foo aMethod * 2) should == 12
+     )
+   )
-   describe(&quot;aBadMethod&quot;,
+   describe("aBadMethod",
-     it(&quot;should signal a condition&quot;,
+     it("should signal a condition",
        fn(Foo aBadMethod) should signal(Condition Error BadBadBed)
+     )
+   )
-)</pre>
+)</source>
 This code first makes sure to use ISpec, then describes Foo. The describe method takes either kinds or texts describing what's under test. This can be nested arbitrarily deep. A test is defined with the &quot;it&quot; method, which takes a text describing the test first, and the implementation of the test as the second argument. If the second argument is left out, the test is considered pending.

← Older revision		Revision as of 00:38, 26 January 2009
Line 1:		Line 1:
−	ISpec is a minimal port of the Ruby RSpec framework for behavior-driven development. It supports the bare minimum to allow testing of Ioke itself. The current Ioke test suite is completely written in ISpec, and it seems to be a capable environment.	+	ISpec is a minimal port of the [http://rspec.info Ruby RSpec] framework for behavior-driven development. It supports the bare minimum to allow testing of Ioke itself. The current Ioke test suite is completely written in ISpec, and it seems to be a capable environment.

	The ispec command line tool takes one argument -- "-f" to specify which format to print in. The default is "p" for progress, which only shows one dot for each test run. The "s" alternative shows the longer spec format. To run all tests in a directory with spec format:		The ispec command line tool takes one argument -- "-f" to specify which format to print in. The default is "p" for progress, which only shows one dot for each test run. The "s" alternative shows the longer spec format. To run all tests in a directory with spec format: