Forum: Ruby on Rails How to disable database setup / teardown in unit tests?

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Robb S. (Guest)
on 2009-03-15 12:44
(Received via mailing list)
Hi,

My app uses a read-only database --- what I need to test is the
parsing code.  I'd like to be able to copy the development database to
test, and run a series of unit tests based on it.

But I can't see how to stop the test system from clearing the data out
for each test.

Any way to do this?

Thanks.
Craig D. (Guest)
on 2009-03-15 14:27
(Received via mailing list)
There's a :purge task in databases.rake in
vendor/rails/railties/lib/tasks.
You'll wan to find a way to avoid calling that when running tests.
I'm interested to see what ideas others might share.

Regards,
Craig


--
Craig D.
Mutually Human Software
http://mutuallyhuman.com
Phlip (Guest)
on 2009-03-15 15:44
(Received via mailing list)
Craig D. wrote:
> There's a :purge task in databases.rake in
> vendor/rails/railties/lib/tasks. You'll wan to find a way to avoid
> calling that when running tests.
>
> I'm interested to see what ideas others might share.

Leave your test database read-write, and load it up with the
test/fixtures
system. Then, in setup(), use Mocha to mock your .save methods (and
.update, and
whatever internal methods they all call), and raise a fault if anyone
calls them.

Always think of mocks as a way to "change reality" - to make random dice
crooked, or to change the clock time. Alternately...

Switch the DB to "read-only" in setup() and turn that off in
"tear-down".

Either way, experiment by trying to .save from a scratch test, to ensure
the
system correctly blows up in your face. The point is to make sure at
production
time it does not!

--
   Phlip
This topic is locked and can not be replied to.