DBUnit for Ruby?

[Daniel Berger]

Hi all,

Is there anyone out there working on something like DBUnit for Ruby?
Or perhaps something like it already exists but I've missed it?

http://www.onjava.com/pub/a/onjava/2004/01/21/dbunit.html

I can do this in TestUnit the "long" way. I just thought it might be
nice to have a subclass of Test::Unit::TestCase that handled some
things automagically, instead of making me do them manually. This
could include stuff like connection handling, and perhaps additional
builtin methods like assert_update, assert_delete. Just an idea.

Suggestions, ideas, comments welcome.

Regards,

Dan

PS - There's a talk on DBUnit at OSCON on Wednesday, July 28th
(4:30-5:15) if anyone is interested in attending for the sake of
gathering ideas.

 

[Michael Neumann]

Hi all,

Is there anyone out there working on something like DBUnit for Ruby?
Or perhaps something like it already exists but I've missed it?

http://www.onjava.com/pub/a/onjava/2004/01/21/dbunit.html

I can do this in TestUnit the "long" way. I just thought it might be
nice to have a subclass of Test::Unit::TestCase that handled some
things automagically, instead of making me do them manually. This
could include stuff like connection handling, and perhaps additional
builtin methods like assert_update, assert_delete. Just an idea.

Suggestions, ideas, comments welcome.

Looks like ActiveRecords's Fixtures. No?

http://ar.rubyonrails.org/classes/Fixtures.html

Regards,

Michael

 

[Shashank Date]

Is there anyone out there working on something like
DBUnit for Ruby?

I am working on TUnit (which is a more specific
solution which works on MS SQL Server 2000 only).

Or perhaps something like it already exists but I've
missed it?

If it does in Ruby, then I have missed it too

I can do this in TestUnit the "long" way. I just
thought it might be
nice to have a subclass of Test::Unit::TestCase
that handled some
things automagically, instead of making me do them
manually. This
could include stuff like connection handling, and
perhaps additional
builtin methods like assert_update, assert_delete.
Just an idea.

Currently this is what I have got:

Microsoft Windows 2000 [Version 5.00.2195]
(C) Copyright 1985-2000 Microsoft Corp.

C:\tunit>dir /b
sample
todo.txt
tst_tunit.sql
TUnit.cmd <<<<<< This can very well be TUnit.rb
tu_assert.sql
tu_assert_column_equal.sql
tu_assert_column_subset.sql
tu_assert_compare_2table_counts.sql
tu_assert_compare_2table_crdt.sql
tu_assert_compare_count.sql
tu_assert_compare_crdt.sql
tu_assert_similar_content.sql
tu_assert_similar_struct.sql
tu_assert_unique_colval.sql
tu_assert_unique_rows.sql
C:\tunit>

Suggestions, ideas, comments welcome.

I think the success of test-unit frameworks is related
to the wealth of "asserts" available and the ease of
their orchestration. To that end, I am continuously
adding to my repertoire of assert and striving to make
it easy to use for ** me **.

I will love for this to be more generic and do what
DBUnit does (and more). Will gladly share what I have
in case anybody is interested.

Regards,

Dan

HTH,
-- shanko




__________________________________
Do you Yahoo!?
Read only the mail you want - Yahoo! Mail SpamGuard.
http://promotions.yahoo.com/new_mail

 

[David Heinemeier Hansson]

Is there anyone out there working on something like DBUnit for Ruby?

Looks like ActiveRecords's Fixtures. No?

http://ar.rubyonrails.org/classes/Fixtures.html

Indeed. I'd dare say that AR's Fixtures (ARF) goes beyond the DBUnit on
some fronts. For example, the example asserts in the article uses the
following form:

EmployeeValueObject vo =
facade.getEmployeeBySocialSecNum("333-29-9999");
TestCase.assertEquals("should be Drew", "Drew", vo.getFirstName());

This repeats the testing literals because the original seed data is not
available to the code. With ARF, you could just reference the seed
data, so that if that you Don't Repeat Yourself unnecessarily:

drew = Employee.find_by_ssn(@emps["drew"]["ssn"])
assert_equals @emps["drew"]["first_name"], drew.first_name

In Rails, we even go one step further. Since you normally have one
production database and one (or more) test databases, it can be quite a
pain to keep the schemas in sync during development. Imagine that you
want to add a birthday field to the employees table. First you'd have
to update two schemas in text for your revision control, then you'd
have to update the actual databases with the changes. Lot of work.

With Rails, the default Rake action will do the following:

1. Take a snapshot of the current production schema and save it to file
(so you can use graphical database tools to update the database, but
still have a text-based schema for the version control).
2. Drop the test database
3. Create a fresh test database based on the schema from the production
database.
4. Insert all the fixtures before each test case (and purge them
afterwards).

With this flow, you can get by solely with editing the production
database schema through a graphical tool (I use the excellent
CocoaMySQL), running the default rake build, and still get all the
benefits of "the long way".
--
David Heinemeier Hansson,
http://www.instiki.org/ -- A No-Step-Three Wiki in Ruby
http://www.basecamphq.com/ -- Web-based Project Management
http://www.loudthinking.com/ -- Broadcasting Brain
http://www.nextangle.com/ -- Development & Consulting Services