Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Ruby > [ANN] BareTest 0.2 released

Reply
Thread Tools

[ANN] BareTest 0.2 released

 
 
apeiros@gmx.net
Guest
Posts: n/a
 
      10-25-2009
I'm pleased to announce BareTest 0.2.

BareTest is a new test framework. I started writing it for mainly 2 reasons:
* I disliked the undescriptive way you have specify tests in vanilla Test::Unit
(def test_bla), compared to the much more descriptive way you do it in e.g.
rspec (it "should have a very nice description")
* I was pretty sure a decent test framework could be written in under 100 lines
of code (and the first version of baretest, written on the flight home from
railsconf09 in vegas, was indeed a whopping 37 lines of code)

By this version, baretest has gotten some - to my knowledge - unique or at least
rare features. Those include:

* Very straightforward and terse assertions (just a block whose return value
defines success/failure).
* Various helpers to write assertions with better diagnostic messages and
more complex tasks like raising, throwing, float imprecision, unordered
collections etc.
* Easy grouping of assertions into suites.
* BDD style specifications/test descriptions (NOT code) that can be extracted
without running the testcode.
* An interactive mode, letting you examine what went wrong in a failing/erroring
test within an irb session, bound to the context of the assertion that failed,
showing you the full code of the assertion, even including it in the readline-
history of that irb session.
* An uncomplicated way to write pending assertions, have dependency testing and
skip certain suites/assertions.
* A colored shell formatter, diagnostic-, XML- and TAP formatter.
* Adding your own formatters is trivial - a module with 4 methods to wrap. The
average formatter shipped with baretest is between 20 and 50 lines.
* An API to use it from code, such as rake tasks (includes an example rake-task)
* A 'baretest' executable to run tests on multiple files at once, using a test-
layout convention to reduce require- and setup-path-manipulation-orgies



The Links:
Home: http://projects.sr.brightlight.ch/pr.../show/baretest
Github: http://github.com/apeiros/baretest
Rubyforge: http://baretest.rubyforge.org
API: http://baretest.rubyforge.org/docs-0.2.0/



How to quickly try baretest without installing it:

1. Download from github and unpack (or clone) - download link:
http://github.com/apeiros/baretest/t...ced07f6eb722ef
2. Change into the baretest directory: `cd the/baretest/directory`
3. Run the examples: `./bin/baretest examples/test.rb`

That's it. Alternatively you can run baretest's own tests, and/or play with
formatters: `./bin/baretest -f tap`



Installing baretest

1. run `gem install baretest` (you may have to run `sudo gem install baretest`)
2. There is no 2.



Installing baretest edge

1. Download from github (or clone)
2. Run `rake gem:install` (you may have to run `sudo rake gem:install`)

Note for users with multiple ruby installations: the rake task will try to use
the right gem executable. You can force it to use a specific one by setting
the GEM env variable, e.g.: `rake gem:install GEM='gem1.9'`



Using baretest

1. In your project directory, run `baretest --init`, which will create a 'tests'
directory with all the basic stuff already in it.
2. Write your tests
3. Run them using `baretest` in the toplevel directory of your project.


That's all folks.
Looking forward to your feedback and hope you enjoy baretest

Regards
Stefan Rusterholz, aka apeiros
--
Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3.5 -
sicherer, schneller und einfacher! http://portal.gmx.net/de/go/atbrowser

 
Reply With Quote
 
 
 
 
Suraj Kurapati
Guest
Posts: n/a
 
      10-25-2009
Stefan Rusterholz wrote:
> By this version, baretest has gotten some - to my knowledge - unique or
> at least rare features.


See http://ruby-toolbox.com/categories/t...rameworks.html

> Those include:
>
> * Very straightforward and terse assertions (just a block whose return
> value defines success/failure).


See assert{ 2.0 } at http://assert2.rubyforge.org/ and also
my Dfect project at http://snk.tuxfamily.org/lib/dfect/

> * An interactive mode, letting you examine what went wrong in a
> failing/erroring test within an irb session, bound to the context of
> the assertion that failed, showing you the full code of the assertion,
> even including it in the readline-history of that irb session.


Excellent! This is a very powerful feature. It is also found in Dfect:

http://snk.tuxfamily.org/lib/dfect/#Motivation

Cheers.
--
Posted via http://www.ruby-forum.com/.

 
Reply With Quote
 
 
 
 
Iñaki Baz Castillo
Guest
Posts: n/a
 
      10-26-2009
El Domingo, 25 de Octubre de 2009, Suraj Kurapati escribi=C3=B3:
> Excellent! This is a very powerful feature. It is also found in Dfect:
>=20
> http://snk.tuxfamily.org/lib/dfect/#Motivation


Hi, about Dfect project I've open a wish/bug report in Git:
http://github.com/sunaku/dfect/issues/#issue/1

Is it the appropriate place for it? or do you prefer it to be reported in t=
his=20
maillist? Thanks.


=2D-=20
I=C3=B1aki Baz Castillo <(E-Mail Removed)>

 
Reply With Quote
 
Suraj Kurapati
Guest
Posts: n/a
 
      10-26-2009
Iñaki Baz Castillo wrote:
> El Domingo, 25 de Octubre de 2009, Suraj Kurapati escribió:
>> Excellent! This is a very powerful feature. It is also found in Dfect:
>>
>> http://snk.tuxfamily.org/lib/dfect/#Motivation

>
> Hi, about Dfect project I've open a wish/bug report in Git:
> http://github.com/sunaku/dfect/issues/#issue/1
>
> Is it the appropriate place for it?


Yes, that is fine. GitHub notified me about that issue by email.

> or do you prefer it to be reported in this maillist? Thanks.


I would prefer the GitHub issue tracker. Thanks for reporting this!
--
Posted via http://www.ruby-forum.com/.

 
Reply With Quote
 
apeiros@gmx.net
Guest
Posts: n/a
 
      10-27-2009
Hi Suraj Kurapati

Thanks for pointing me to the other test frameworks.

> See assert{ 2.0 } at http://assert2.rubyforge.org/


As I've understood, assert { 2.0 } still uses the method name to identify what shall be verified. Also it seems to come with its own set of problems.

> my Dfect project at http://snk.tuxfamily.org/lib/dfect/


Looks good. But personally, I prefer intuitive method names, and I don't think single character method names are intuitive in most cases.
Also, baretest manages to get you all the power you need in only 2 methods

An example baretest testfile, something I should have added to the first post already:


# examples/test.rb - can be run without installing baretest by downloading
# it from github and run ./bin/baretest examples/test.rb
BareTest.suite do
# assertions and refutations can be grouped in suites. They will share
# setup and teardown
# they don't have to be in suites, though
suite "Success" do
assert "An assertion returning a trueish value (non nil/false) is a success" do
true
end
end

suite "Failure" do
assert "An assertion returning a falsish value (nil/false) is a failure" do
false
end
end

suite "Pending" do
assert "An assertion without a block is pending"
end

suite "Error" do
assert "Uncaught exceptions in an assertion are an error" do
raise "Error!"
end
end

suite "Special assertions" do
assert "Assert a block to raise" do
raises do
sleep(rand()/3+0.05)
raise "If this raises then the assertion is a success"
end
end

assert "Assert a float to be close to another" do
a = 0.18 - 0.01
b = 0.17
within_delta a, b, 0.001
end

suite "Nested suite" do
assert "Assert two randomly ordered arrays to contain the same values" do
a = [*"A".."Z"] # an array with values from A to Z
b = a.sort_by { rand }
equal_unordered(a, b) # can be used with any Enumerable, uses hash-key identity
end
end
end

suite "Setup & Teardown" do
setup do
@foo = "foo"
@bar = "bar"
end

assert "@foo should be set" do
@foo == "foo"
end

suite "Nested suite" do
setup do
@bar = "inner bar"
@baz = "baz"
end

assert "@foo is inherited" do
@foo == "foo"
end

assert "@bar is overridden" do
@bar == "inner bar"
end

assert "@baz is defined only for inner" do
@baz == "baz"
end
end

teardown do
@foo = nil # not that it'd make much sense, just to demonstrate
end
end

suite "Dependencies", :requires => ['foo', 'bar'] do
assert "Will be skipped, due to unsatisfied dependencies" do
failure "Why the heck do you have a 'foo/bar' file?"
end
end
end


Regards
Stefan Rusterholz, (apeiros @ irc.freenode.org & twitter)

--
GRATIS fr alle GMX-Mitglieder: Die maxdome Movie-FLAT!
Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01

 
Reply With Quote
 
Suraj Kurapati
Guest
Posts: n/a
 
      10-27-2009
Stefan Rusterholz wrote:
>> See assert{ 2.0 } at http://assert2.rubyforge.org/

>
> Also it seems to come with its own set of problems.


Don't we all?

>> my Dfect project at http://snk.tuxfamily.org/lib/dfect/

>
> Looks good. But personally, I prefer intuitive method names, and I don't
> think single character method names are intuitive in most cases.


Thanks, I agree. That's why I created emulation layers to mimic
other popular testing libraries, such as Test::Unit and RSpec,
inside Dfect. That way, I can use a similar sugary syntax to
write my tests, but with Dfect running the show under the hood.

> Also, baretest manages to get you all the power you need in only 2
> methods


I see more than two methods: suite, assert, failure, raises, etc.

Perhaps I have misunderstood?

> An example baretest testfile, something I should have added to the first
> post already:
>[...]


Thanks for the example. Your method name choices seem very natural.
I think I'll make an emulation layer for BareTest in Dfect soon.

Cheers.
--
Posted via http://www.ruby-forum.com/.

 
Reply With Quote
 
apeiros@gmx.net
Guest
Posts: n/a
 
      10-27-2009
> > Also, baretest manages to get you all the power you need in only 2
> > methods

>
> I see more than two methods: suite, assert, failure, raises, etc.
>
> Perhaps I have misunderstood?


2 Methods is the minimum you need to use it in a productive way: suite and assert.

There are various more methods, e.g. setup & teardown in suite, and many predefined helper methods exist in BareTest::Assertion::Support (see http://baretest.rubyforge.org/docs-0...n/Support.html)

But those are just to make it easier and nicer to write tests. Sugar if you want.

> > An example baretest testfile, something I should have added to the first
> > post already:
> >[...]

>
> Thanks for the example. Your method name choices seem very natural.
> I think I'll make an emulation layer for BareTest in Dfect soon.


Heh, I'll be surprised if you manage to emulate it 100%. But I'm flattered

> Cheers.


To you too. Good luck with DFECT

Regards
Stefan
--
Neu: GMX DSL bis 50.000 kBit/s und 200,- Euro Startguthaben!
http://portal.gmx.net/de/go/dsl02

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Win XP wireless network adapter gets released and then connects ba =?Utf-8?B?cGkyMmJ5Nw==?= Wireless Networking 1 08-01-2008 08:33 PM
Battlefield 2 New Patch Released (yet Again...) Silverstrand Front Page News 4 07-20-2005 04:33 PM
*Mozilla Firefox 1.0.4 Released* Roland Firefox 4 05-13-2005 03:05 PM
Firefox 1.0.1 released Z Firefox 2 02-26-2005 04:11 AM
ANN: Anyplace Control 2.6 released Yura Goncharuk Wireless Networking 0 09-28-2004 10:13 AM



Advertisments