ANN: DocTest 0.0.1 version code-name: bazooka

[Roger Pack]

I have recently coded up an implementation of Doctest for Ruby.
Kind of ugly, but it works.


DocTest Explanation:
Or rather, example:

Here are some examples copied from
http://clintonforbes.blogspot.com/2007/08/doctest-for-ruby-and-rails.html

=begin
#doctest Check that 1 + 1 = 2=> 5
=end

And it outputs something like this

Looking for doctests in 3 files
Processing 'script/../app/helpers/application_helper.rb'
Testing 'Check strings'...OK
Testing 'Check that 1 + 1 = 2'...OK
Testing 'Add some arrays'...OK
Testing 'Check that 2 + 2 = 4 and 4 + 4 = 7'...FAILED
Code:
4 + 4
Expected: 7
But got: 8
Processing 'script/../app/models/member.rb'
Testing 'Test creating a Member'...OK
Total tests: 5, Succeeded: 4

You can also add explanations between lines

=begin
#doctest Check that 1 + 1 = 2=> 2
It should also work for other than 1's=> 5
=end

You'll note that this is just copied and pasted working output from an
irb session. You can add these anywhere in your file.

Advantages

The advantages of using this is that it creates tests that are somewhat
behavior oriented [behavior of a method], and the tests serve as a kind
of documentation for the code. And it is dirt easy and fast to create
these kind of tests. I like it because I don't have to think as much to
do the testing.

Installation [it's not yet a real rubygem]

Download
http://ruby-roger-useful-functions.googlecode.com/svn/trunk/packages/doctest/pkg/doctest-0.0.1.gem
run [sudo] gem install doctest-0.0.1.gem

Here's the page for any feedback:
http://code.google.com/p/ruby-roger-useful-functions/wiki/DocTest

 

[Trans]

I have recently coded up an implementation of Doctest for Ruby.
Kind of ugly, but it works.

DocTest Explanation:
Or rather, example:

Here are some examples copied fromhttp://clintonforbes.blogspot.com/2007/08/doctest-for-ruby-and-rails....

=begin
#doctest Check that 1 + 1 = 2>> 1 + 1
=> 2
=> 5
=end

And it outputs something like this

Looking for doctests in 3 files
Processing 'script/../app/helpers/application_helper.rb'
Testing 'Check strings'...OK
Testing 'Check that 1 + 1 = 2'...OK
Testing 'Add some arrays'...OK
Testing 'Check that 2 + 2 = 4 and 4 + 4 = 7'...FAILED
Code:
4 + 4
Expected: 7
But got: 8
Processing 'script/../app/models/member.rb'
Testing 'Test creating a Member'...OK
Total tests: 5, Succeeded: 4

You can also add explanations between lines

=begin
#doctest Check that 1 + 1 = 2>> 1 + 1

=> 2
It should also work for other than 1's>> 2 + 3

=> 5
=end

You'll note that this is just copied and pasted working output from an
irb session. You can add these anywhere in your file.

Advantages

The advantages of using this is that it creates tests that are somewhat
behavior oriented [behavior of a method], and the tests serve as a kind
of documentation for the code. And it is dirt easy and fast to create
these kind of tests. I like it because I don't have to think as much to
do the testing.

Installation [it's not yet a real rubygem]

Downloadhttp://ruby-roger-useful-functions.googlecode.com/svn/trunk/packages/...
run [sudo] gem install doctest-0.0.1.gem

Here's the page for any feedback:http://code.google.com/p/ruby-roger-useful-functions/wiki/DocTest

Hi--

I did something like this for a long time. But instead of a test
framework, I just integrated it with test/unit (or any test suite you
wish to use). The layout was simple:

=begin test

require 'test/unit'

# normal test unit code here

=end

I had a tool that could extract these sections into test/ files, or
run them directly. Later I realized I could just use a general text
extract tool (I wrote a simple multi-line grep utility) and pipe the
result to Ruby.

I really liked this system, however I stopped using it because it was
unconventional and while it was great for unit tests, it didn;t help
with integrated tests. I figure if I was going to have to maintain any
of those, I might as well maintain the unit test files too. In other
words I preferred having just a single approach. However, I do miss it
some times. It was really nice to have the tests right there and be
able to rubnthem so easily when working on code.

T.

 

[Roger Pack]

Hi--

I did something like this for a long time. But instead of a test
framework, I just integrated it with test/unit (or any test suite you
wish to use). The layout was simple:

That's a great idea--allow for 'normal' code tests, as well. Then
people can do more integrated-y tests. I like it.

words I preferred having just a single approach. However, I do miss it
some times. It was really nice to have the tests right there and be
able to rubnthem so easily when working on code.

Yeah I agree that having tests right next to the code is very nice. I
also like it because it doesn't seem to interrupt my flow of coding as
much.
-R