[rspec-devel] [ANN] quicktest - an RSpec wrapper for in-lining tests

greg weber webs.dev at gmail.com
Wed Feb 27 10:27:18 EST 2008


On Wed, Feb 27, 2008 at 6:23 AM, Corey Haines <coreyhaines at gmail.com> wrote:

> It is definitely an interesting thing to try out. I've only used doctest
> once, and we quickly moved out of using it into a separate class.
>
> How do you see this being used with external examples? Replace external
> with inline? Used in conjunction? If it is used in conjunction, what cases
> do you see when you would use the inline?
>
> I'm not trying to shoot the idea down, I'm just trying to start a
> conversation about where this would be most useful. thanks.
>
> -Corey
>

Tests are a form of documentation.  It can be argued that it is better to
have all documentation in the source, but I don't believe that.

It is definitely very useful for one file scripts, or any type of code that
does not have a well established project home where the tests will be.  You
can distribute the tests with script so that anyone who wants to modify it
can also modify the tests instead of assuming the original author did not
write any.
You can have a flow of development where a 'quick and dirty' script becomes
well tested.  You can create a shell function so that you would be testing
the file before every run.
function test_run () { quickspec $1 && $1 }

Otherwise, it is designed as a tool for test-driven development.  When
writing fresh code you now have the possibility to be directly next to the
code under test without having to switch back and forth between files.  When
you are done writing the new code, you can easily pull all the quicktest
methods out and into a spec file.


 Greg

>
>
> On Wed, Feb 27, 2008 at 12:55 AM, greg weber <webs.dev at gmail.com> wrote:
>
> > On Tue, Feb 26, 2008 at 5:53 PM, Corey Haines <coreyhaines at gmail.com>
> > wrote:
> >
> > > This is interesting. I really like the python doctest stuff, but,
> > > while using it with a friend on writing something, it seemed almost to start
> > > to get cumbersome for lots of examples. I have several specs per method, so
> > > I wonder how it scales.
> > >
> > > -Corey
> > >
> >
> > It probably doesn't scale very well- but you can put as many 'it' blocks
> > as you like in the quicktest method.  Python doctest is an interesting
> > concept- but relying on printed representations of data is limiting and
> > fragile.
> > Quicktest came out of my dabbling in the D programming language, which
> > allows you to place testing blocks inline with your source code
> > unittest{
> >  ...
> > }
> >
> > Normally, these blocks are ignored, but if you compile with a different
> > switch, they are linked in and ran at the beginning of your program.
> > Originally, I made an exact copy of this, but among other things, it
> > requires the placement of a line like
> > (def unittest;end) if not defined? unittest
> > at the beginning of the file.  It would be nice if Ruby had a similar
> > construct built in.
> >
> >
> > > On Tue, Feb 26, 2008 at 3:54 PM, Matthijs Langenberg <
> > > mlangenberg at gmail.com> wrote:
> > >
> > > > It would almost be possible to generate the actual ruby code from
> > > > the quicktest method ;-).
> > > >
> > > > To be honest, I like it that my examples don't mix with the actual
> > > > code, it looks a bit cleaner. Interesting approach though, maybe I'll give
> > > > it a shot.
> > > >
> > > >
> > > > On Tue, Feb 26, 2008 at 1:56 PM, greg weber <webs.dev at gmail.com>
> > > > wrote:
> > > >
> > > > >  == ABOUT
> > > > > Quicktest is a utility for inlining ruby unit tests with the ruby
> > > > > code under test
> > > > >
> > > > > The typical test driven development workflow requires constant
> > > > > switching between the file containg the source code and the the file
> > > > > containg the tests. When creating code, it can be more convenient to place
> > > > > tests immediately after the code you are writing.  After the code has been
> > > > > written, it may be a good idea to move it to another file, but the option to
> > > > > permanently keep tests with the source is available (useful for scripts).
> > > > >
> > > > > Quicktest is designed to support quick tests in a framework
> > > > > agnostic way.  Currently, only an rspec testrunner is available, but it is
> > > > > trivial to write one for another testing framework.
> > > > >
> > > > > == FEATURES
> > > > > Quicktest uses method tracing to know the method you are testing.
> > > > > By default the output of a failed test will show the object and method name.
> > > > >
> > > > > == USAGE
> > > > > To test a method, place another method called 'quicktest'
> > > > > immediately after it
> > > > > the quicktest method has three OPTIONAL arguments
> > > > > - the test runner object
> > > > > - a reference to self
> > > > > - a method object for the method under test
> > > > >
> > > > > run with spec -r quicktest file_to_test
> > > > >
> > > > > There is a convenience script so that you can just run
> > > > >
> > > > >    quickspec file_to_test
> > > > >
> > > > > == NOTES
> > > > > - leaving test code in with your production code is not
> > > > > necessarily a good idea, but there is almost no runtime overhead to doing so
> > > > > since ruby will not evaluate code in a method until the method is invoked
> > > > > - quicktest instance methods not working properly? if the class
> > > > > (or one of its ancestors) is overriding method tracing than including
> > > > > QuickTest::Tracer will fix it.
> > > > >
> > > > >
> > > > > example: run with bin/quickspec
> > > > >
> > > > > class Foo
> > > > >   attr_reader :bar
> > > > >
> > > > >   def initialize
> > > > >     @bar = true
> > > > >   end
> > > > >   def quicktest t, s
> > > > >     t.it "bar should be initialized to true" do
> > > > >       s.bar.should == true
> > > > >     end
> > > > >   end
> > > > >
> > > > >   def self.hello arg
> > > > >     "hello" + arg
> > > > >   end
> > > > >   def self.quicktest t, s, meth
> > > > >     t.it "should prepend 'hello' to its argument" do
> > > > >       meth["world"].should == 'hello world' # error - no space
> > > > > 'helloworld'
> > > > >     end
> > > > >   end
> > > > > end
> > > > >
> > > > >
> > > > > Running quicktest on the above outputs the following:
> > > > > .F
> > > > >
> > > > > 1)
> > > > > 'Foo hello should prepend 'hello' to its argument' FAILED
> > > > > expected: "hello world",
> > > > >      got: "helloworld" (using ==)
> > > > > ./README:22:in `quicktest'
> > > > > /home/greg/quicktest/lib/quicktest.rb:65:in `instance_eval'
> > > > > /home/greg/quicktest/lib/quicktest.rb:65:in `run_tests'
> > > > >
> > > > > Finished in 0.008338 seconds
> > > > >
> > > > > 2 examples, 1 failure
> > > > >
> > > > > _______________________________________________
> > > > > rspec-devel mailing list
> > > > > rspec-devel at rubyforge.org
> > > > > http://rubyforge.org/mailman/listinfo/rspec-devel
> > > > >
> > > >
> > > >
> > > > _______________________________________________
> > > > rspec-devel mailing list
> > > > rspec-devel at rubyforge.org
> > > > http://rubyforge.org/mailman/listinfo/rspec-devel
> > > >
> > >
> > >
> > >
> > > --
> > > http://www.coreyhaines.com
> > > The Internet's Premiere source of information about Corey Haines
> > > _______________________________________________
> > > rspec-devel mailing list
> > > rspec-devel at rubyforge.org
> > > http://rubyforge.org/mailman/listinfo/rspec-devel
> > >
> >
> >
> > _______________________________________________
> > rspec-devel mailing list
> > rspec-devel at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/rspec-devel
> >
>
>
>
> --
> http://www.coreyhaines.com
> The Internet's Premiere source of information about Corey Haines
>
> _______________________________________________
> rspec-devel mailing list
> rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20080227/801e99fc/attachment.html 


More information about the rspec-devel mailing list