Open jdudek opened 13 years ago
2) at least documenting this behavior in Readme, to minimize users confusion
It should be documented anyway.
There is also a hack for shared connection: https://gist.github.com/470808
My point is that unless we have some big future plans for Bbq::TestCase
which are unknown to me we should make it a Module instead of a Class a ppl could include it if they need support for nice api or something. I don't use bbq
with Bbq::TestCase
and I don't think we should teach people to do it or autogenerate it or force them to do so. I've got my own test class that already knows how to clean db after tests etc and inheriting from Bbq::TestCase
does not give me any additional value. The point is to make bbq
as simple as possible and to let people cherry-pick those features that they need/want. Do you agree? That's why I think we should make Bbq::TestCase
a module. I'm talking about it here because I do not want Bbq::TestCase
to grow larger with fixes for such cases.
Mentioning use_transactional_fixtures
in readme is sufficient in my opinion. People using Capybara (The Capybaras?
) are already familiar with the consequences of running it in selenium mode and tools like DatabaseCleaner. I don't think that forcing use_transactional_fixtures
to be false inside Bbq::TestCase
is the right solution because it add some burden for cases when you use RackTest. There is a very good note about it on capybara readme https://github.com/jnicklas/capybara and we could simply point people there.
We could provide module Bbq::TestCase::NonTransactional
, which would disable transactional fixtures and set up DatabaseCleaner. This would simplify using Selenium to just including a module in user's test case.
What do you think?
@jdudek - There are many DatabaseCleaner strategies I do not feel comfortable with choosing one of them for ppl. I like the idea in case it is possible for people to somehow change the strategy after NonTransactional
is included. Otherwise I would just provide as much information as possible in readme and let people do it themselves. I don't think it is hard, complicated or takes lot of coding to do it.
By default Bbq tests run with
use_transactional_fixtures = true
. Accessing database within test case will run in a transaction, separate from application server (at least when running Selenium). As a result, changes made by test won't be visible to the application.Although direct access to the database is discouraged in acceptance tests, sometimes it's very useful and not harmful. Creating admin user account might be a good example.
Possible solutions include 1) setting
use_transactional_fixtures = false
inside Bbq::TestCase 2) at least documenting this behavior in Readme, to minimize users confusion