Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Transactional fixtures break database access in test #13

Open
jdudek opened this issue Jul 2, 2011 · 5 comments
Open

Transactional fixtures break database access in test #13

jdudek opened this issue Jul 2, 2011 · 5 comments
Assignees
Labels

Comments

@jdudek
Copy link
Member

jdudek commented Jul 2, 2011

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
@mostlyobvious
Copy link
Member

  1. 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

@paneq
Copy link
Member

paneq commented Jul 3, 2011

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.

@jdudek
Copy link
Member Author

jdudek commented Jul 3, 2011

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?

@paneq
Copy link
Member

paneq commented Jul 3, 2011

@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.

@ghost ghost assigned mostlyobvious Jan 6, 2013
@mostlyobvious
Copy link
Member

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants