I just started using Capybara with JavaScript, so hopefully I'm just
making some newbie kind of mistake. (Before I forget: Thanks for great
gem!)
Don't know if this makes a difference, but... Ubuntu 10.10, Ruby
1.9.2, Rails 3.0.5, FireFox 4.0, Cucumber 0.10.2, Capybara 0.4.1.2,
Selenium-Webdriver 0.1.4.
* I just Bundle>Updated most of the gems today, so they should be the
latest and greatest versions.
At the beginning of the test I populate a database with some items. I
display a handful of them - along with a listbox - on the initial "GET
index" action. When I change the selection in the listbox I use
JavaScript (jQuery) to populate the page with a different set of
items. Typical vanilla operations.
It all works fine in development mode, and when I run my Cucumber
tests without the @javascript tag everything works fine until I get to
the test for the "new items corresponding to the new listbox
selection" - which makes sense because there are no new items because
the test is not yet using Selenium/JavaScript.
Before I change the listbox selection I test for the presence of the
initial items and that test passes. Also, I do a 'save_and_open_page'
and I can see that the initial list of items is indeed on the web
page, just waiting to be changed according to the new listbox
selection.
This leads me to believe that all of the plumbing is hooked up
correctly.
Now, when I put the @javascript tag before my "Scenario:" statement,
Capybara dutifully fires up the browser, but there are no initial
items on the web page. The listbox is there and it contains the right
choices, but my first "are the initial items on the page" test (that
used to pass) now fails because there's nothing there.
I increased the 'Capybara.default_wait_time' but that didn't make a
difference. Which I guess it shouldn't because I think that's just for
dynamic JavaScript interactions, and this problem is with the initial
page load not containing the initial database elements.
Can someone please help me? I have spent soooo much time on this...
On Thu, Mar 31, 2011 at 10:51 PM, Larry <i...@stupidtuesday.com> wrote: > Hi,
> I just started using Capybara with JavaScript, so hopefully I'm just > making some newbie kind of mistake. (Before I forget: Thanks for great > gem!)
> Don't know if this makes a difference, but... Ubuntu 10.10, Ruby > 1.9.2, Rails 3.0.5, FireFox 4.0, Cucumber 0.10.2, Capybara 0.4.1.2, > Selenium-Webdriver 0.1.4. > * I just Bundle>Updated most of the gems today, so they should be the > latest and greatest versions.
> At the beginning of the test I populate a database with some items. I > display a handful of them - along with a listbox - on the initial "GET > index" action. When I change the selection in the listbox I use > JavaScript (jQuery) to populate the page with a different set of > items. Typical vanilla operations.
> It all works fine in development mode, and when I run my Cucumber > tests without the @javascript tag everything works fine until I get to > the test for the "new items corresponding to the new listbox > selection" - which makes sense because there are no new items because > the test is not yet using Selenium/JavaScript.
> Before I change the listbox selection I test for the presence of the > initial items and that test passes. Also, I do a 'save_and_open_page' > and I can see that the initial list of items is indeed on the web > page, just waiting to be changed according to the new listbox > selection.
> This leads me to believe that all of the plumbing is hooked up > correctly.
> Now, when I put the @javascript tag before my "Scenario:" statement, > Capybara dutifully fires up the browser, but there are no initial > items on the web page. The listbox is there and it contains the right > choices, but my first "are the initial items on the page" test (that > used to pass) now fails because there's nothing there.
> I increased the 'Capybara.default_wait_time' but that didn't make a > difference. Which I guess it shouldn't because I think that's just for > dynamic JavaScript interactions, and this problem is with the initial > page load not containing the initial database elements.
> Can someone please help me? I have spent soooo much time on this...
Thanks for the reply. I already did that. It's only in my "test"
section (along with capybara and launchy), but that should be the only
place it's needed, right?
It's weird. Basically, I have 5 items in the database and 2 in the
listbox. When the page first loads I should see 3 elements and the
listbox - which I do in development mode and when running cuke tests
without the @javascript tag. (Like I said, I see the 3 elements on the
page when I do a "save_and_open_page", so I know the creation part is
okay.)
But when I run the test with @javascript the browser pops up showing
the listbox... but not the 3 elements. Then it just sits there looking
for the initial 3 elements until it times out, at which point the
browser disappears and the test officially fails.
Any other ideas? (I hope ;-)
Thanks,
Larry
On Mar 31, 7:28 pm, Jonas Nicklas <jonas.nick...@gmail.com> wrote:
> Make sure to add the database_cleaner gem to your gemfile.
> /Jonas
> On Thu, Mar 31, 2011 at 10:51 PM, Larry <i...@stupidtuesday.com> wrote:
> > Hi,
> > I just started using Capybara with JavaScript, so hopefully I'm just
> > making some newbie kind of mistake. (Before I forget: Thanks for great
> > gem!)
> > Don't know if this makes a difference, but... Ubuntu 10.10, Ruby
> > 1.9.2, Rails 3.0.5, FireFox 4.0, Cucumber 0.10.2, Capybara 0.4.1.2,
> > Selenium-Webdriver 0.1.4.
> > * I just Bundle>Updated most of the gems today, so they should be the
> > latest and greatest versions.
> > At the beginning of the test I populate a database with some items. I
> > display a handful of them - along with a listbox - on the initial "GET
> > index" action. When I change the selection in the listbox I use
> > JavaScript (jQuery) to populate the page with a different set of
> > items. Typical vanilla operations.
> > It all works fine in development mode, and when I run my Cucumber
> > tests without the @javascript tag everything works fine until I get to
> > the test for the "new items corresponding to the new listbox
> > selection" - which makes sense because there are no new items because
> > the test is not yet using Selenium/JavaScript.
> > Before I change the listbox selection I test for the presence of the
> > initial items and that test passes. Also, I do a 'save_and_open_page'
> > and I can see that the initial list of items is indeed on the web
> > page, just waiting to be changed according to the new listbox
> > selection.
> > This leads me to believe that all of the plumbing is hooked up
> > correctly.
> > Now, when I put the @javascript tag before my "Scenario:" statement,
> > Capybara dutifully fires up the browser, but there are no initial
> > items on the web page. The listbox is there and it contains the right
> > choices, but my first "are the initial items on the page" test (that
> > used to pass) now fails because there's nothing there.
> > I increased the 'Capybara.default_wait_time' but that didn't make a
> > difference. Which I guess it shouldn't because I think that's just for
> > dynamic JavaScript interactions, and this problem is with the initial
> > page load not containing the initial database elements.
> > Can someone please help me? I have spent soooo much time on this...
> Thanks for the reply. I already did that. It's only in my "test" > section (along with capybara and launchy), but that should be the only > place it's needed, right?
> It's weird. Basically, I have 5 items in the database and 2 in the > listbox. When the page first loads I should see 3 elements and the > listbox - which I do in development mode and when running cuke tests > without the @javascript tag. (Like I said, I see the 3 elements on the > page when I do a "save_and_open_page", so I know the creation part is > okay.)
> But when I run the test with @javascript the browser pops up showing > the listbox... but not the 3 elements. Then it just sits there looking > for the initial 3 elements until it times out, at which point the > browser disappears and the test officially fails.
> Any other ideas? (I hope ;-)
> Thanks, > Larry
> On Mar 31, 7:28 pm, Jonas Nicklas <jonas.nick...@gmail.com> wrote: >> Make sure to add the database_cleaner gem to your gemfile.
>> /Jonas
>> On Thu, Mar 31, 2011 at 10:51 PM, Larry <i...@stupidtuesday.com> wrote: >>> Hi,
>>> I just started using Capybara with JavaScript, so hopefully I'm just >>> making some newbie kind of mistake. (Before I forget: Thanks for great >>> gem!)
>>> Don't know if this makes a difference, but... Ubuntu 10.10, Ruby >>> 1.9.2, Rails 3.0.5, FireFox 4.0, Cucumber 0.10.2, Capybara 0.4.1.2, >>> Selenium-Webdriver 0.1.4. >>> * I just Bundle>Updated most of the gems today, so they should be the >>> latest and greatest versions.
>>> At the beginning of the test I populate a database with some items. I >>> display a handful of them - along with a listbox - on the initial "GET >>> index" action. When I change the selection in the listbox I use >>> JavaScript (jQuery) to populate the page with a different set of >>> items. Typical vanilla operations.
>>> It all works fine in development mode, and when I run my Cucumber >>> tests without the @javascript tag everything works fine until I get to >>> the test for the "new items corresponding to the new listbox >>> selection" - which makes sense because there are no new items because >>> the test is not yet using Selenium/JavaScript.
>>> Before I change the listbox selection I test for the presence of the >>> initial items and that test passes. Also, I do a 'save_and_open_page' >>> and I can see that the initial list of items is indeed on the web >>> page, just waiting to be changed according to the new listbox >>> selection.
>>> This leads me to believe that all of the plumbing is hooked up >>> correctly.
>>> Now, when I put the @javascript tag before my "Scenario:" statement, >>> Capybara dutifully fires up the browser, but there are no initial >>> items on the web page. The listbox is there and it contains the right >>> choices, but my first "are the initial items on the page" test (that >>> used to pass) now fails because there's nothing there.
>>> I increased the 'Capybara.default_wait_time' but that didn't make a >>> difference. Which I guess it shouldn't because I think that's just for >>> dynamic JavaScript interactions, and this problem is with the initial >>> page load not containing the initial database elements.
>>> Can someone please help me? I have spent soooo much time on this...
Thanks for the heads-up on this issue. I can really relate to the
misery expressed in some of those comments ;-). When I woke up
yesterday morning I thought I'd have the cucumber tests I wanted to
write done in a couple of hours and then I'd be able to move on to
something else. Late last night I was still working on this issue...
sigh. The only thing that makes me feel good about this is that I know
we all go through these things on a fairly regular basis. (And that
there might be a fix forthcoming :-)
Guess I'll monitor that issue and wait for a fix.
In the meantime, thanks to you and Jonas for your help, and to the
Capybara team for providing this great gem!
-- Larry
P.S. Okay, instead of waiting I decided to do what they suggested:
take the provided code patch and stick it in my env.rb file. That
didn't solve the problem. Did you try the fix, and if so, did it work
for you?
On Apr 1, 5:04 am, Matt Wynne <m...@mattwynne.net> wrote:
> > Thanks for the reply. I already did that. It's only in my "test"
> > section (along with capybara and launchy), but that should be the only
> > place it's needed, right?
> > It's weird. Basically, I have 5 items in the database and 2 in the
> > listbox. When the page first loads I should see 3 elements and the
> > listbox - which I do in development mode and when running cuke tests
> > without the @javascript tag. (Like I said, I see the 3 elements on the
> > page when I do a "save_and_open_page", so I know the creation part is
> > okay.)
> > But when I run the test with @javascript the browser pops up showing
> > the listbox... but not the 3 elements. Then it just sits there looking
> > for the initial 3 elements until it times out, at which point the
> > browser disappears and the test officially fails.
> > Any other ideas? (I hope ;-)
> > Thanks,
> > Larry
> > On Mar 31, 7:28 pm, Jonas Nicklas <jonas.nick...@gmail.com> wrote:
> >> Make sure to add the database_cleaner gem to your gemfile.
> >> /Jonas
> >> On Thu, Mar 31, 2011 at 10:51 PM, Larry <i...@stupidtuesday.com> wrote:
> >>> Hi,
> >>> I just started using Capybara with JavaScript, so hopefully I'm just
> >>> making some newbie kind of mistake. (Before I forget: Thanks for great
> >>> gem!)
> >>> Don't know if this makes a difference, but... Ubuntu 10.10, Ruby
> >>> 1.9.2, Rails 3.0.5, FireFox 4.0, Cucumber 0.10.2, Capybara 0.4.1.2,
> >>> Selenium-Webdriver 0.1.4.
> >>> * I just Bundle>Updated most of the gems today, so they should be the
> >>> latest and greatest versions.
> >>> At the beginning of the test I populate a database with some items. I
> >>> display a handful of them - along with a listbox - on the initial "GET
> >>> index" action. When I change the selection in the listbox I use
> >>> JavaScript (jQuery) to populate the page with a different set of
> >>> items. Typical vanilla operations.
> >>> It all works fine in development mode, and when I run my Cucumber
> >>> tests without the @javascript tag everything works fine until I get to
> >>> the test for the "new items corresponding to the new listbox
> >>> selection" - which makes sense because there are no new items because
> >>> the test is not yet using Selenium/JavaScript.
> >>> Before I change the listbox selection I test for the presence of the
> >>> initial items and that test passes. Also, I do a 'save_and_open_page'
> >>> and I can see that the initial list of items is indeed on the web
> >>> page, just waiting to be changed according to the new listbox
> >>> selection.
> >>> This leads me to believe that all of the plumbing is hooked up
> >>> correctly.
> >>> Now, when I put the @javascript tag before my "Scenario:" statement,
> >>> Capybara dutifully fires up the browser, but there are no initial
> >>> items on the web page. The listbox is there and it contains the right
> >>> choices, but my first "are the initial items on the page" test (that
> >>> used to pass) now fails because there's nothing there.
> >>> I increased the 'Capybara.default_wait_time' but that didn't make a
> >>> difference. Which I guess it shouldn't because I think that's just for
> >>> dynamic JavaScript interactions, and this problem is with the initial
> >>> page load not containing the initial database elements.
> >>> Can someone please help me? I have spent soooo much time on this...
> P.S. Okay, instead of waiting I decided to do what they suggested: > take the provided code patch and stick it in my env.rb file. That > didn't solve the problem. Did you try the fix, and if so, did it work > for you?
As I said in the comment, I can't vouch for the monkey patch. Try @markus' fork of cucumber-rails instead, that's working for me.
>>> Thanks for the reply. I already did that. It's only in my "test" >>> section (along with capybara and launchy), but that should be the only >>> place it's needed, right?
>>> It's weird. Basically, I have 5 items in the database and 2 in the >>> listbox. When the page first loads I should see 3 elements and the >>> listbox - which I do in development mode and when running cuke tests >>> without the @javascript tag. (Like I said, I see the 3 elements on the >>> page when I do a "save_and_open_page", so I know the creation part is >>> okay.)
>>> But when I run the test with @javascript the browser pops up showing >>> the listbox... but not the 3 elements. Then it just sits there looking >>> for the initial 3 elements until it times out, at which point the >>> browser disappears and the test officially fails.
>>> Any other ideas? (I hope ;-)
>>> Thanks, >>> Larry
>>> On Mar 31, 7:28 pm, Jonas Nicklas <jonas.nick...@gmail.com> wrote: >>>> Make sure to add the database_cleaner gem to your gemfile.
>>>> /Jonas
>>>> On Thu, Mar 31, 2011 at 10:51 PM, Larry <i...@stupidtuesday.com> wrote: >>>>> Hi,
>>>>> I just started using Capybara with JavaScript, so hopefully I'm just >>>>> making some newbie kind of mistake. (Before I forget: Thanks for great >>>>> gem!)
>>>>> Don't know if this makes a difference, but... Ubuntu 10.10, Ruby >>>>> 1.9.2, Rails 3.0.5, FireFox 4.0, Cucumber 0.10.2, Capybara 0.4.1.2, >>>>> Selenium-Webdriver 0.1.4. >>>>> * I just Bundle>Updated most of the gems today, so they should be the >>>>> latest and greatest versions.
>>>>> At the beginning of the test I populate a database with some items. I >>>>> display a handful of them - along with a listbox - on the initial "GET >>>>> index" action. When I change the selection in the listbox I use >>>>> JavaScript (jQuery) to populate the page with a different set of >>>>> items. Typical vanilla operations.
>>>>> It all works fine in development mode, and when I run my Cucumber >>>>> tests without the @javascript tag everything works fine until I get to >>>>> the test for the "new items corresponding to the new listbox >>>>> selection" - which makes sense because there are no new items because >>>>> the test is not yet using Selenium/JavaScript.
>>>>> Before I change the listbox selection I test for the presence of the >>>>> initial items and that test passes. Also, I do a 'save_and_open_page' >>>>> and I can see that the initial list of items is indeed on the web >>>>> page, just waiting to be changed according to the new listbox >>>>> selection.
>>>>> This leads me to believe that all of the plumbing is hooked up >>>>> correctly.
>>>>> Now, when I put the @javascript tag before my "Scenario:" statement, >>>>> Capybara dutifully fires up the browser, but there are no initial >>>>> items on the web page. The listbox is there and it contains the right >>>>> choices, but my first "are the initial items on the page" test (that >>>>> used to pass) now fails because there's nothing there.
>>>>> I increased the 'Capybara.default_wait_time' but that didn't make a >>>>> difference. Which I guess it shouldn't because I think that's just for >>>>> dynamic JavaScript interactions, and this problem is with the initial >>>>> page load not containing the initial database elements.
>>>>> Can someone please help me? I have spent soooo much time on this...
My problem still remains, and I hope someone can shed some light on it
because I'm dead in the water.
I have a simple setup and gem configuration, i.e. nothing too complex
or crazy. I have several records that I'd like to display in an
"index" action. Again, simple stuff. When I run my Cucumber test
without @javascript/selenium it works fine. In fact, when I do a
"save_and_open_page" I can see the records on the page.
However, when I add the @javascript tag, selenium fires up the
browser, but the page is empty. And there's no way I can do any
javascript/selenium testing without any database content.
Print statements verify the records are being successfully created,
but nothing is retrieved from the database. I found a recent RailsCast
where Ryan talked about a similar issue, but with RSpec instead of
Cucumber. Here is what the corresponding AsciiCast said (http://
asciicasts.com/episodes/257-request-specs-and-capybara):
=======================================================================
This time the first spec fails as the content “paint fence” is missing
from the page. The database record that is created isn’t available to
the Selenium tests and this is because our specs are using database
transactions which aren’t compatible with Selenium. To fix this we can
set the config.use_transactional_fixtures setting in the spec_helper
file to false.
This will get the tests passing again but it will mean that the
database records are carried over between specs which we don’t want.
To solve this problem we can use a gem called database_cleaner to
clean the database between specs.
=======================================================================
That seems to be what's happening to me, except I'm using Cucumber
instead of RSpec. Any help anyone can provide on this subject will be
greatly appreciated.
Thanks,
Larry
On Apr 1, 9:03 am, Matt Wynne <m...@mattwynne.net> wrote:
> > P.S. Okay, instead of waiting I decided to do what they suggested:
> > take the provided code patch and stick it in my env.rb file. That
> > didn't solve the problem. Did you try the fix, and if so, did it work
> > for you?
> As I said in the comment, I can't vouch for the monkey patch. Try @markus' fork of cucumber-rails instead, that's working for me.
> > On Apr 1, 5:04 am, Matt Wynne <m...@mattwynne.net> wrote:
> >> This might be a bug in the latest version of cucumber-rails which bit me recently.
> >>> Thanks for the reply. I already did that. It's only in my "test"
> >>> section (along with capybara and launchy), but that should be the only
> >>> place it's needed, right?
> >>> It's weird. Basically, I have 5 items in the database and 2 in the
> >>> listbox. When the page first loads I should see 3 elements and the
> >>> listbox - which I do in development mode and when running cuke tests
> >>> without the @javascript tag. (Like I said, I see the 3 elements on the
> >>> page when I do a "save_and_open_page", so I know the creation part is
> >>> okay.)
> >>> But when I run the test with @javascript the browser pops up showing
> >>> the listbox... but not the 3 elements. Then it just sits there looking
> >>> for the initial 3 elements until it times out, at which point the
> >>> browser disappears and the test officially fails.
> >>> Any other ideas? (I hope ;-)
> >>> Thanks,
> >>> Larry
> >>> On Mar 31, 7:28 pm, Jonas Nicklas <jonas.nick...@gmail.com> wrote:
> >>>> Make sure to add the database_cleaner gem to your gemfile.
> >>>> /Jonas
> >>>> On Thu, Mar 31, 2011 at 10:51 PM, Larry <i...@stupidtuesday.com> wrote:
> >>>>> Hi,
> >>>>> I just started using Capybara with JavaScript, so hopefully I'm just
> >>>>> making some newbie kind of mistake. (Before I forget: Thanks for great
> >>>>> gem!)
> >>>>> Don't know if this makes a difference, but... Ubuntu 10.10, Ruby
> >>>>> 1.9.2, Rails 3.0.5, FireFox 4.0, Cucumber 0.10.2, Capybara 0.4.1.2,
> >>>>> Selenium-Webdriver 0.1.4.
> >>>>> * I just Bundle>Updated most of the gems today, so they should be the
> >>>>> latest and greatest versions.
> >>>>> At the beginning of the test I populate a database with some items. I
> >>>>> display a handful of them - along with a listbox - on the initial "GET
> >>>>> index" action. When I change the selection in the listbox I use
> >>>>> JavaScript (jQuery) to populate the page with a different set of
> >>>>> items. Typical vanilla operations.
> >>>>> It all works fine in development mode, and when I run my Cucumber
> >>>>> tests without the @javascript tag everything works fine until I get to
> >>>>> the test for the "new items corresponding to the new listbox
> >>>>> selection" - which makes sense because there are no new items because
> >>>>> the test is not yet using Selenium/JavaScript.
> >>>>> Before I change the listbox selection I test for the presence of the
> >>>>> initial items and that test passes. Also, I do a 'save_and_open_page'
> >>>>> and I can see that the initial list of items is indeed on the web
> >>>>> page, just waiting to be changed according to the new listbox
> >>>>> selection.
> >>>>> This leads me to believe that all of the plumbing is hooked up
> >>>>> correctly.
> >>>>> Now, when I put the @javascript tag before my "Scenario:" statement,
> >>>>> Capybara dutifully fires up the browser, but there are no initial
> >>>>> items on the web page. The listbox is there and it contains the right
> >>>>> choices, but my first "are the initial items on the page" test (that
> >>>>> used to pass) now fails because there's nothing there.
> >>>>> I increased the 'Capybara.default_wait_time' but that didn't make a
> >>>>> difference. Which I guess it shouldn't because I think that's just for
> >>>>> dynamic JavaScript interactions, and this problem is with the initial
> >>>>> page load not containing the initial database elements.
> >>>>> Can someone please help me? I have spent soooo much time on this...
You need to debug this somehow. I'd suggest removing the cucumber Database cleaner stuff entirely (iirc you need to remove the line that requires somthing like cucumber/active_record) and get your own setup going. The cucumber way, is very convoluted and error prone, imo.
Personally I just drop this in my projects http://pastie.org/1745020. It's a hack suggested originally by Jose Valim which forces ActiveRecord to always use the same connection, which will make transactions work with Capybara. Not only is it significantly faster, you also never have to deal with junk in the database, and you don't need DatabaseCleaner at all. It's a win-win, imho. Give it a shot!
> My problem still remains, and I hope someone can shed some light on it > because I'm dead in the water.
> I have a simple setup and gem configuration, i.e. nothing too complex > or crazy. I have several records that I'd like to display in an > "index" action. Again, simple stuff. When I run my Cucumber test > without @javascript/selenium it works fine. In fact, when I do a > "save_and_open_page" I can see the records on the page.
> However, when I add the @javascript tag, selenium fires up the > browser, but the page is empty. And there's no way I can do any > javascript/selenium testing without any database content.
> Print statements verify the records are being successfully created, > but nothing is retrieved from the database. I found a recent RailsCast > where Ryan talked about a similar issue, but with RSpec instead of > Cucumber. Here is what the corresponding AsciiCast said (http:// > asciicasts.com/episodes/257-request-specs-and-capybara):
> ======================================================================= > This time the first spec fails as the content “paint fence” is missing > from the page. The database record that is created isn’t available to > the Selenium tests and this is because our specs are using database > transactions which aren’t compatible with Selenium. To fix this we can > set the config.use_transactional_fixtures setting in the spec_helper > file to false.
> This will get the tests passing again but it will mean that the > database records are carried over between specs which we don’t want. > To solve this problem we can use a gem called database_cleaner to > clean the database between specs. > =======================================================================
> That seems to be what's happening to me, except I'm using Cucumber > instead of RSpec. Any help anyone can provide on this subject will be > greatly appreciated.
> Thanks, > Larry
> On Apr 1, 9:03 am, Matt Wynne <m...@mattwynne.net> wrote: >> On 1 Apr 2011, at 13:14, Larry wrote:
>> > P.S. Okay, instead of waiting I decided to do what they suggested: >> > take the provided code patch and stick it in my env.rb file. That >> > didn't solve the problem. Did you try the fix, and if so, did it work >> > for you?
>> As I said in the comment, I can't vouch for the monkey patch. Try @markus' fork of cucumber-rails instead, that's working for me.
>> > On Apr 1, 5:04 am, Matt Wynne <m...@mattwynne.net> wrote: >> >> This might be a bug in the latest version of cucumber-rails which bit me recently.
>> >>> Thanks for the reply. I already did that. It's only in my "test" >> >>> section (along with capybara and launchy), but that should be the only >> >>> place it's needed, right?
>> >>> It's weird. Basically, I have 5 items in the database and 2 in the >> >>> listbox. When the page first loads I should see 3 elements and the >> >>> listbox - which I do in development mode and when running cuke tests >> >>> without the @javascript tag. (Like I said, I see the 3 elements on the >> >>> page when I do a "save_and_open_page", so I know the creation part is >> >>> okay.)
>> >>> But when I run the test with @javascript the browser pops up showing >> >>> the listbox... but not the 3 elements. Then it just sits there looking >> >>> for the initial 3 elements until it times out, at which point the >> >>> browser disappears and the test officially fails.
>> >>> Any other ideas? (I hope ;-)
>> >>> Thanks, >> >>> Larry
>> >>> On Mar 31, 7:28 pm, Jonas Nicklas <jonas.nick...@gmail.com> wrote: >> >>>> Make sure to add the database_cleaner gem to your gemfile.
>> >>>> /Jonas
>> >>>> On Thu, Mar 31, 2011 at 10:51 PM, Larry <i...@stupidtuesday.com> wrote: >> >>>>> Hi,
>> >>>>> I just started using Capybara with JavaScript, so hopefully I'm just >> >>>>> making some newbie kind of mistake. (Before I forget: Thanks for great >> >>>>> gem!)
>> >>>>> Don't know if this makes a difference, but... Ubuntu 10.10, Ruby >> >>>>> 1.9.2, Rails 3.0.5, FireFox 4.0, Cucumber 0.10.2, Capybara 0.4.1.2, >> >>>>> Selenium-Webdriver 0.1.4. >> >>>>> * I just Bundle>Updated most of the gems today, so they should be the >> >>>>> latest and greatest versions.
>> >>>>> At the beginning of the test I populate a database with some items. I >> >>>>> display a handful of them - along with a listbox - on the initial "GET >> >>>>> index" action. When I change the selection in the listbox I use >> >>>>> JavaScript (jQuery) to populate the page with a different set of >> >>>>> items. Typical vanilla operations.
>> >>>>> It all works fine in development mode, and when I run my Cucumber >> >>>>> tests without the @javascript tag everything works fine until I get to >> >>>>> the test for the "new items corresponding to the new listbox >> >>>>> selection" - which makes sense because there are no new items because >> >>>>> the test is not yet using Selenium/JavaScript.
>> >>>>> Before I change the listbox selection I test for the presence of the >> >>>>> initial items and that test passes. Also, I do a 'save_and_open_page' >> >>>>> and I can see that the initial list of items is indeed on the web >> >>>>> page, just waiting to be changed according to the new listbox >> >>>>> selection.
>> >>>>> This leads me to believe that all of the plumbing is hooked up >> >>>>> correctly.
>> >>>>> Now, when I put the @javascript tag before my "Scenario:" statement, >> >>>>> Capybara dutifully fires up the browser, but there are no initial >> >>>>> items on the web page. The listbox is there and it contains the right >> >>>>> choices, but my first "are the initial items on the page" test (that >> >>>>> used to pass) now fails because there's nothing there.
>> >>>>> I increased the 'Capybara.default_wait_time' but that didn't make a >> >>>>> difference. Which I guess it shouldn't because I think that's just for >> >>>>> dynamic JavaScript interactions, and this problem is with the initial >> >>>>> page load not containing the initial database elements.
>> >>>>> Can someone please help me? I have spent soooo much time on this...
> You need to debug this somehow. I'd suggest removing the cucumber > Database cleaner stuff entirely (iirc you need to remove the line that > requires somthing like cucumber/active_record) and get your own setup > going. The cucumber way, is very convoluted and error prone, imo.
> Personally I just drop this in my projects http://pastie.org/1745020. > It's a hack suggested originally by Jose Valim which forces > ActiveRecord to always use the same connection, which will make > transactions work with Capybara. Not only is it significantly faster, > you also never have to deal with junk in the database, and you don't > need DatabaseCleaner at all. It's a win-win, imho. Give it a shot!
> /Jonas
> On Fri, Apr 1, 2011 at 9:49 PM, Larry <i...@stupidtuesday.com> wrote: >> Hi,
>> My problem still remains, and I hope someone can shed some light on it >> because I'm dead in the water.
>> I have a simple setup and gem configuration, i.e. nothing too complex >> or crazy. I have several records that I'd like to display in an >> "index" action. Again, simple stuff. When I run my Cucumber test >> without @javascript/selenium it works fine. In fact, when I do a >> "save_and_open_page" I can see the records on the page.
>> However, when I add the @javascript tag, selenium fires up the >> browser, but the page is empty. And there's no way I can do any >> javascript/selenium testing without any database content.
>> Print statements verify the records are being successfully created, >> but nothing is retrieved from the database. I found a recent RailsCast >> where Ryan talked about a similar issue, but with RSpec instead of >> Cucumber. Here is what the corresponding AsciiCast said (http:// >> asciicasts.com/episodes/257-request-specs-and-capybara):
>> ======================================================================= >> This time the first spec fails as the content “paint fence” is missing >> from the page. The database record that is created isn’t available to >> the Selenium tests and this is because our specs are using database >> transactions which aren’t compatible with Selenium. To fix this we can >> set the config.use_transactional_fixtures setting in the spec_helper >> file to false.
>> This will get the tests passing again but it will mean that the >> database records are carried over between specs which we don’t want. >> To solve this problem we can use a gem called database_cleaner to >> clean the database between specs. >> =======================================================================
>> That seems to be what's happening to me, except I'm using Cucumber >> instead of RSpec. Any help anyone can provide on this subject will be >> greatly appreciated.
>> Thanks, >> Larry
>> On Apr 1, 9:03 am, Matt Wynne <m...@mattwynne.net> wrote: >>> On 1 Apr 2011, at 13:14, Larry wrote:
>>>> P.S. Okay, instead of waiting I decided to do what they suggested: >>>> take the provided code patch and stick it in my env.rb file. That >>>> didn't solve the problem. Did you try the fix, and if so, did it work >>>> for you?
>>> As I said in the comment, I can't vouch for the monkey patch. Try @markus' fork of cucumber-rails instead, that's working for me.
>>>> On Apr 1, 5:04 am, Matt Wynne <m...@mattwynne.net> wrote: >>>>> This might be a bug in the latest version of cucumber-rails which bit me recently.
>>>>>> Thanks for the reply. I already did that. It's only in my "test" >>>>>> section (along with capybara and launchy), but that should be the only >>>>>> place it's needed, right?
>>>>>> It's weird. Basically, I have 5 items in the database and 2 in the >>>>>> listbox. When the page first loads I should see 3 elements and the >>>>>> listbox - which I do in development mode and when running cuke tests >>>>>> without the @javascript tag. (Like I said, I see the 3 elements on the >>>>>> page when I do a "save_and_open_page", so I know the creation part is >>>>>> okay.)
>>>>>> But when I run the test with @javascript the browser pops up showing >>>>>> the listbox... but not the 3 elements. Then it just sits there looking >>>>>> for the initial 3 elements until it times out, at which point the >>>>>> browser disappears and the test officially fails.
>>>>>> Any other ideas? (I hope ;-)
>>>>>> Thanks, >>>>>> Larry
>>>>>> On Mar 31, 7:28 pm, Jonas Nicklas <jonas.nick...@gmail.com> wrote: >>>>>>> Make sure to add the database_cleaner gem to your gemfile.
>>>>>>> /Jonas
>>>>>>> On Thu, Mar 31, 2011 at 10:51 PM, Larry <i...@stupidtuesday.com> wrote: >>>>>>>> Hi,
>>>>>>>> I just started using Capybara with JavaScript, so hopefully I'm just >>>>>>>> making some newbie kind of mistake. (Before I forget: Thanks for great >>>>>>>> gem!)
>>>>>>>> Don't know if this makes a difference, but... Ubuntu 10.10, Ruby >>>>>>>> 1.9.2, Rails 3.0.5, FireFox 4.0, Cucumber 0.10.2, Capybara 0.4.1.2, >>>>>>>> Selenium-Webdriver 0.1.4. >>>>>>>> * I just Bundle>Updated most of the gems today, so they should be the >>>>>>>> latest and greatest versions.
>>>>>>>> At the beginning of the test I populate a database with some items. I >>>>>>>> display a handful of them - along with a listbox - on the initial "GET >>>>>>>> index" action. When I change the selection in the listbox I use >>>>>>>> JavaScript (jQuery) to populate the page with a different set of >>>>>>>> items. Typical vanilla operations.
>>>>>>>> It all works fine in development mode, and when I run my Cucumber >>>>>>>> tests without the @javascript tag everything works fine until I get to >>>>>>>> the test for the "new items corresponding to the new listbox >>>>>>>> selection" - which makes sense because there are no new items because >>>>>>>> the test is not yet using Selenium/JavaScript.
>>>>>>>> Before I change the listbox selection I test for the presence of the >>>>>>>> initial items and that test passes. Also, I do a 'save_and_open_page' >>>>>>>> and I can see that the initial list of items is indeed on the web >>>>>>>> page, just waiting to be changed according to the new listbox >>>>>>>> selection.
>>>>>>>> This leads me to believe that all of the plumbing is hooked up >>>>>>>> correctly.
>>>>>>>> Now, when I put the @javascript tag before my "Scenario:" statement, >>>>>>>> Capybara dutifully fires up the browser, but there are no initial >>>>>>>> items on the web page. The listbox is there and it contains the right >>>>>>>> choices, but my first "are the initial items on the page" test (that >>>>>>>> used to pass) now fails because there's nothing there.
>>>>>>>> I increased the 'Capybara.default_wait_time' but that didn't make a >>>>>>>> difference. Which I guess it shouldn't because I think that's just for >>>>>>>> dynamic JavaScript interactions, and this problem is with the initial >>>>>>>> page load not containing the initial database elements.
>>>>>>>> Can someone please help me? I have spent soooo much time on this...
First things first: Matt and Jonas - thanks a LOT for helping me (and
hopefully others) with this issue. I know you must be busy and it
would've been easier for you to simply wash your hands of this and
wish me good luck. But you didn't, and I really appreciate that. (Yet
another thing I love about the Ruby and Rails community!)
I'll detail what I did for those of you playing along at home (and
then ask a final question at the end, just to keep you guys on your
toes ;-)
1) I removed the 'gem database_cleaner' statement from my Gemfile, and
the gem itself from its RVM-managed directory.
2) I couldn't find a 'require cucumber/active_record' statement, but I
did find and comment out the following line:
<gem-directory>/cucumber-rails-0.4.0/lib/cucumber/rails/hooks.rb :
'require 'cucumber/rails/hooks/database_cleaner'
3) I created /features/support/local_env.rb and inserted the code
Jonas pointed me to at http://pastie.org/1745020
What the heck, it's short, so here it is in case that link ever gets
hosed or removed:
==========================================
class ActiveRecord::Base
mattr_accessor :shared_connection
@@shared_connection = nil
def self.connection
@@shared_connection || retrieve_connection
end
end
# Forces all threads to share the same connection. This works on
# Capybara because it starts the web server in a thread.
ActiveRecord::Base.shared_connection = ActiveRecord::Base.connection
==========================================
And it worked like a charm! Again, thanks a lot, and here's your
rewards-bonus question! ;-)
This fixed my Cucumber/Capybara/Selenium problem, but could it ever
cause problems in development or (more importantly) production mode?
Do you think it would be a good idea to slap an "if Rails.env.test?"
statement around the fix?
Thanks again,
Larry
On Apr 1, 4:47 pm, Matt Wynne <m...@mattwynne.net> wrote:
> Also, for debugging, watch your logs/test.log file very closely during a simple test-case and see if you can decipher anything from that.
> On 1 Apr 2011, at 21:34, Jonas Nicklas wrote:
> > You need to debug this somehow. I'd suggest removing the cucumber
> > Database cleaner stuff entirely (iirc you need to remove the line that
> > requires somthing like cucumber/active_record) and get your own setup
> > going. The cucumber way, is very convoluted and error prone, imo.
> > Personally I just drop this in my projectshttp://pastie.org/1745020.
> > It's a hack suggested originally by Jose Valim which forces
> > ActiveRecord to always use the same connection, which will make
> > transactions work with Capybara. Not only is it significantly faster,
> > you also never have to deal with junk in the database, and you don't
> > need DatabaseCleaner at all. It's a win-win, imho. Give it a shot!
> > /Jonas
> > On Fri, Apr 1, 2011 at 9:49 PM, Larry <i...@stupidtuesday.com> wrote:
> >> Hi,
> >> My problem still remains, and I hope someone can shed some light on it
> >> because I'm dead in the water.
> >> I have a simple setup and gem configuration, i.e. nothing too complex
> >> or crazy. I have several records that I'd like to display in an
> >> "index" action. Again, simple stuff. When I run my Cucumber test
> >> without @javascript/selenium it works fine. In fact, when I do a
> >> "save_and_open_page" I can see the records on the page.
> >> However, when I add the @javascript tag, selenium fires up the
> >> browser, but the page is empty. And there's no way I can do any
> >> javascript/selenium testing without any database content.
> >> Print statements verify the records are being successfully created,
> >> but nothing is retrieved from the database. I found a recent RailsCast
> >> where Ryan talked about a similar issue, but with RSpec instead of
> >> Cucumber. Here is what the corresponding AsciiCast said (http://
> >> asciicasts.com/episodes/257-request-specs-and-capybara):
> >> =======================================================================
> >> This time the first spec fails as the content “paint fence” is missing
> >> from the page. The database record that is created isn’t available to
> >> the Selenium tests and this is because our specs are using database
> >> transactions which aren’t compatible with Selenium. To fix this we can
> >> set the config.use_transactional_fixtures setting in the spec_helper
> >> file to false.
> >> This will get the tests passing again but it will mean that the
> >> database records are carried over between specs which we don’t want.
> >> To solve this problem we can use a gem called database_cleaner to
> >> clean the database between specs.
> >> =======================================================================
> >> That seems to be what's happening to me, except I'm using Cucumber
> >> instead of RSpec. Any help anyone can provide on this subject will be
> >> greatly appreciated.
> >> Thanks,
> >> Larry
> >> On Apr 1, 9:03 am, Matt Wynne <m...@mattwynne.net> wrote:
> >>> On 1 Apr 2011, at 13:14, Larry wrote:
> >>>> P.S. Okay, instead of waiting I decided to do what they suggested:
> >>>> take the provided code patch and stick it in my env.rb file. That
> >>>> didn't solve the problem. Did you try the fix, and if so, did it work
> >>>> for you?
> >>> As I said in the comment, I can't vouch for the monkey patch. Try @markus' fork of cucumber-rails instead, that's working for me.
> >>>> On Apr 1, 5:04 am, Matt Wynne <m...@mattwynne.net> wrote:
> >>>>> This might be a bug in the latest version of cucumber-rails which bit me recently.
> >>>>>> Thanks for the reply. I already did that. It's only in my "test"
> >>>>>> section (along with capybara and launchy), but that should be the only
> >>>>>> place it's needed, right?
> >>>>>> It's weird. Basically, I have 5 items in the database and 2 in the
> >>>>>> listbox. When the page first loads I should see 3 elements and the
> >>>>>> listbox - which I do in development mode and when running cuke tests
> >>>>>> without the @javascript tag. (Like I said, I see the 3 elements on the
> >>>>>> page when I do a "save_and_open_page", so I know the creation part is
> >>>>>> okay.)
> >>>>>> But when I run the test with @javascript the browser pops up showing
> >>>>>> the listbox... but not the 3 elements. Then it just sits there looking
> >>>>>> for the initial 3 elements until it times out, at which point the
> >>>>>> browser disappears and the test officially fails.
> >>>>>> Any other ideas? (I hope ;-)
> >>>>>> Thanks,
> >>>>>> Larry
> >>>>>> On Mar 31, 7:28 pm, Jonas Nicklas <jonas.nick...@gmail.com> wrote:
> >>>>>>> Make sure to add the database_cleaner gem to your gemfile.
> >>>>>>> /Jonas
> >>>>>>> On Thu, Mar 31, 2011 at 10:51 PM, Larry <i...@stupidtuesday.com> wrote:
> >>>>>>>> Hi,
> >>>>>>>> I just started using Capybara with JavaScript, so hopefully I'm just
> >>>>>>>> making some newbie kind of mistake. (Before I forget: Thanks for great
> >>>>>>>> gem!)
> >>>>>>>> Don't know if this makes a difference, but... Ubuntu 10.10, Ruby
> >>>>>>>> 1.9.2, Rails 3.0.5, FireFox 4.0, Cucumber 0.10.2, Capybara 0.4.1.2,
> >>>>>>>> Selenium-Webdriver 0.1.4.
> >>>>>>>> * I just Bundle>Updated most of the gems today, so they should be the
> >>>>>>>> latest and greatest versions.
> >>>>>>>> At the beginning of the test I populate a database with some items. I
> >>>>>>>> display a handful of them - along with a listbox - on the initial "GET
> >>>>>>>> index" action. When I change the selection in the listbox I use
> >>>>>>>> JavaScript (jQuery) to populate the page with a different set of
> >>>>>>>> items. Typical vanilla operations.
> >>>>>>>> It all works fine in development mode, and when I run my Cucumber
> >>>>>>>> tests without the @javascript tag everything works fine until I get to
> >>>>>>>> the test for the "new items corresponding to the new listbox
> >>>>>>>> selection" - which makes sense because there are no new items because
> >>>>>>>> the test is not yet using Selenium/JavaScript.
> >>>>>>>> Before I change the listbox selection I test for the presence of the
> >>>>>>>> initial items and that test passes. Also, I do a 'save_and_open_page'
> >>>>>>>> and I can see that the initial list of items is indeed on the web
> >>>>>>>> page, just waiting to be changed according to the new listbox
> >>>>>>>> selection.
> >>>>>>>> This leads me to believe that all of the plumbing is hooked up
> >>>>>>>> correctly.
> >>>>>>>> Now, when I put the @javascript tag before my "Scenario:" statement,
> >>>>>>>> Capybara dutifully fires up the browser, but there are no initial
> >>>>>>>> items on the web page. The listbox is there and it contains the right
> >>>>>>>> choices, but my first "are the initial items on the page" test (that
> >>>>>>>> used to pass) now fails because there's nothing there.
> >>>>>>>> I increased the 'Capybara.default_wait_time' but that didn't make a
> >>>>>>>> difference. Which I guess it shouldn't because I think that's just for
> >>>>>>>> dynamic JavaScript interactions, and this problem is with the initial
> >>>>>>>> page load not containing the initial database elements.
> >>>>>>>> Can someone please help me? I have spent soooo much time on this...
Yes, you should definitely not be loading that code in production. In most cases it won't make a difference, but if you ever move to a threaded environment, you'll be in a world of pain with a tricky to debug issue. Save yourself the trouble and only load it in the test env (I usually put it in features/support/shared_connection.rb or something)
On Mon, Apr 4, 2011 at 4:16 PM, Larry <i...@stupidtuesday.com> wrote: > YES!!!
> First things first: Matt and Jonas - thanks a LOT for helping me (and > hopefully others) with this issue. I know you must be busy and it > would've been easier for you to simply wash your hands of this and > wish me good luck. But you didn't, and I really appreciate that. (Yet > another thing I love about the Ruby and Rails community!)
> I'll detail what I did for those of you playing along at home (and > then ask a final question at the end, just to keep you guys on your > toes ;-)
> 1) I removed the 'gem database_cleaner' statement from my Gemfile, and > the gem itself from its RVM-managed directory. > 2) I couldn't find a 'require cucumber/active_record' statement, but I > did find and comment out the following line: > <gem-directory>/cucumber-rails-0.4.0/lib/cucumber/rails/hooks.rb : > 'require 'cucumber/rails/hooks/database_cleaner' > 3) I created /features/support/local_env.rb and inserted the code > Jonas pointed me to at http://pastie.org/1745020
> What the heck, it's short, so here it is in case that link ever gets > hosed or removed:
> def self.connection > @@shared_connection || retrieve_connection > end > end
> # Forces all threads to share the same connection. This works on > # Capybara because it starts the web server in a thread. > ActiveRecord::Base.shared_connection = ActiveRecord::Base.connection > ==========================================
> And it worked like a charm! Again, thanks a lot, and here's your > rewards-bonus question! ;-)
> This fixed my Cucumber/Capybara/Selenium problem, but could it ever > cause problems in development or (more importantly) production mode? > Do you think it would be a good idea to slap an "if Rails.env.test?" > statement around the fix?
> Thanks again, > Larry
> On Apr 1, 4:47 pm, Matt Wynne <m...@mattwynne.net> wrote: >> Also, for debugging, watch your logs/test.log file very closely during a simple test-case and see if you can decipher anything from that.
>> On 1 Apr 2011, at 21:34, Jonas Nicklas wrote:
>> > You need to debug this somehow. I'd suggest removing the cucumber >> > Database cleaner stuff entirely (iirc you need to remove the line that >> > requires somthing like cucumber/active_record) and get your own setup >> > going. The cucumber way, is very convoluted and error prone, imo.
>> > Personally I just drop this in my projectshttp://pastie.org/1745020. >> > It's a hack suggested originally by Jose Valim which forces >> > ActiveRecord to always use the same connection, which will make >> > transactions work with Capybara. Not only is it significantly faster, >> > you also never have to deal with junk in the database, and you don't >> > need DatabaseCleaner at all. It's a win-win, imho. Give it a shot!
>> > /Jonas
>> > On Fri, Apr 1, 2011 at 9:49 PM, Larry <i...@stupidtuesday.com> wrote: >> >> Hi,
>> >> My problem still remains, and I hope someone can shed some light on it >> >> because I'm dead in the water.
>> >> I have a simple setup and gem configuration, i.e. nothing too complex >> >> or crazy. I have several records that I'd like to display in an >> >> "index" action. Again, simple stuff. When I run my Cucumber test >> >> without @javascript/selenium it works fine. In fact, when I do a >> >> "save_and_open_page" I can see the records on the page.
>> >> However, when I add the @javascript tag, selenium fires up the >> >> browser, but the page is empty. And there's no way I can do any >> >> javascript/selenium testing without any database content.
>> >> Print statements verify the records are being successfully created, >> >> but nothing is retrieved from the database. I found a recent RailsCast >> >> where Ryan talked about a similar issue, but with RSpec instead of >> >> Cucumber. Here is what the corresponding AsciiCast said (http:// >> >> asciicasts.com/episodes/257-request-specs-and-capybara):
>> >> ======================================================================= >> >> This time the first spec fails as the content “paint fence” is missing >> >> from the page. The database record that is created isn’t available to >> >> the Selenium tests and this is because our specs are using database >> >> transactions which aren’t compatible with Selenium. To fix this we can >> >> set the config.use_transactional_fixtures setting in the spec_helper >> >> file to false.
>> >> This will get the tests passing again but it will mean that the >> >> database records are carried over between specs which we don’t want. >> >> To solve this problem we can use a gem called database_cleaner to >> >> clean the database between specs. >> >> =======================================================================
>> >> That seems to be what's happening to me, except I'm using Cucumber >> >> instead of RSpec. Any help anyone can provide on this subject will be >> >> greatly appreciated.
>> >> Thanks, >> >> Larry
>> >> On Apr 1, 9:03 am, Matt Wynne <m...@mattwynne.net> wrote: >> >>> On 1 Apr 2011, at 13:14, Larry wrote:
>> >>>> P.S. Okay, instead of waiting I decided to do what they suggested: >> >>>> take the provided code patch and stick it in my env.rb file. That >> >>>> didn't solve the problem. Did you try the fix, and if so, did it work >> >>>> for you?
>> >>> As I said in the comment, I can't vouch for the monkey patch. Try @markus' fork of cucumber-rails instead, that's working for me.
>> >>>> On Apr 1, 5:04 am, Matt Wynne <m...@mattwynne.net> wrote: >> >>>>> This might be a bug in the latest version of cucumber-rails which bit me recently.
>> >>>>>> Thanks for the reply. I already did that. It's only in my "test" >> >>>>>> section (along with capybara and launchy), but that should be the only >> >>>>>> place it's needed, right?
>> >>>>>> It's weird. Basically, I have 5 items in the database and 2 in the >> >>>>>> listbox. When the page first loads I should see 3 elements and the >> >>>>>> listbox - which I do in development mode and when running cuke tests >> >>>>>> without the @javascript tag. (Like I said, I see the 3 elements on the >> >>>>>> page when I do a "save_and_open_page", so I know the creation part is >> >>>>>> okay.)
>> >>>>>> But when I run the test with @javascript the browser pops up showing >> >>>>>> the listbox... but not the 3 elements. Then it just sits there looking >> >>>>>> for the initial 3 elements until it times out, at which point the >> >>>>>> browser disappears and the test officially fails.
>> >>>>>> Any other ideas? (I hope ;-)
>> >>>>>> Thanks, >> >>>>>> Larry
>> >>>>>> On Mar 31, 7:28 pm, Jonas Nicklas <jonas.nick...@gmail.com> wrote: >> >>>>>>> Make sure to add the database_cleaner gem to your gemfile.
>> >>>>>>> /Jonas
>> >>>>>>> On Thu, Mar 31, 2011 at 10:51 PM, Larry <i...@stupidtuesday.com> wrote: >> >>>>>>>> Hi,
>> >>>>>>>> I just started using Capybara with JavaScript, so hopefully I'm just >> >>>>>>>> making some newbie kind of mistake. (Before I forget: Thanks for great >> >>>>>>>> gem!)
>> >>>>>>>> Don't know if this makes a difference, but... Ubuntu 10.10, Ruby >> >>>>>>>> 1.9.2, Rails 3.0.5, FireFox 4.0, Cucumber 0.10.2, Capybara 0.4.1.2, >> >>>>>>>> Selenium-Webdriver 0.1.4. >> >>>>>>>> * I just Bundle>Updated most of the gems today, so they should be the >> >>>>>>>> latest and greatest versions.
>> >>>>>>>> At the beginning of the test I populate a database with some items. I >> >>>>>>>> display a handful of them - along with a listbox - on the initial "GET >> >>>>>>>> index" action. When I change the selection in the listbox I use >> >>>>>>>> JavaScript (jQuery) to populate the page with a different set of >> >>>>>>>> items. Typical vanilla operations.
>> >>>>>>>> It all works fine in development mode, and when I run my Cucumber >> >>>>>>>> tests without the @javascript tag everything works fine until I get to >> >>>>>>>> the test for the "new items corresponding to the new listbox >> >>>>>>>> selection" - which makes sense because there are no new items because >> >>>>>>>> the test is not yet using Selenium/JavaScript.
>> >>>>>>>> Before I change the listbox selection I test for the presence of the >> >>>>>>>> initial items and that test passes. Also, I do a 'save_and_open_page' >> >>>>>>>> and I can see that the initial list of items is indeed on the web >> >>>>>>>> page, just waiting to be changed according to the new listbox >> >>>>>>>> selection.
>> >>>>>>>> This leads me to believe that all of the plumbing is hooked up >> >>>>>>>> correctly.
>> >>>>>>>> Now, when I put the @javascript tag before my "Scenario:" statement, >> >>>>>>>> Capybara dutifully fires up the browser, but there are no initial >> >>>>>>>> items on the web page. The listbox is there and it contains the right >> >>>>>>>> choices, but my first "are the initial items on the page" test (that >> >>>>>>>> used to pass) now fails because there's nothing there.
>> >>>>>>>> I increased the 'Capybara.default_wait_time' but that didn't make a
> Yes, you should definitely not be loading that code in production. In
> most cases it won't make a difference, but if you ever move to a
> threaded environment, you'll be in a world of pain with a tricky to
> debug issue. Save yourself the trouble and only load it in the test
> env (I usually put it in features/support/shared_connection.rb or
> something)
> /Jonas
> On Mon, Apr 4, 2011 at 4:16 PM, Larry <i...@stupidtuesday.com> wrote:
> > YES!!!
> > First things first: Matt and Jonas - thanks a LOT for helping me (and
> > hopefully others) with this issue. I know you must be busy and it
> > would've been easier for you to simply wash your hands of this and
> > wish me good luck. But you didn't, and I really appreciate that. (Yet
> > another thing I love about the Ruby and Rails community!)
> > I'll detail what I did for those of you playing along at home (and
> > then ask a final question at the end, just to keep you guys on your
> > toes ;-)
> > 1) I removed the 'gem database_cleaner' statement from my Gemfile, and
> > the gem itself from its RVM-managed directory.
> > 2) I couldn't find a 'require cucumber/active_record' statement, but I
> > did find and comment out the following line:
> > <gem-directory>/cucumber-rails-0.4.0/lib/cucumber/rails/hooks.rb :
> > 'require 'cucumber/rails/hooks/database_cleaner'
> > 3) I created /features/support/local_env.rb and inserted the code
> > Jonas pointed me to athttp://pastie.org/1745020
> > What the heck, it's short, so here it is in case that link ever gets
> > hosed or removed:
> > def self.connection
> > @@shared_connection || retrieve_connection
> > end
> > end
> > # Forces all threads to share the same connection. This works on
> > # Capybara because it starts the web server in a thread.
> > ActiveRecord::Base.shared_connection = ActiveRecord::Base.connection
> > ==========================================
> > And it worked like a charm! Again, thanks a lot, and here's your
> > rewards-bonus question! ;-)
> > This fixed my Cucumber/Capybara/Selenium problem, but could it ever
> > cause problems in development or (more importantly) production mode?
> > Do you think it would be a good idea to slap an "if Rails.env.test?"
> > statement around the fix?
> > Thanks again,
> > Larry
> > On Apr 1, 4:47 pm, Matt Wynne <m...@mattwynne.net> wrote:
> >> Also, for debugging, watch your logs/test.log file very closely during a simple test-case and see if you can decipher anything from that.
> >> On 1 Apr 2011, at 21:34, Jonas Nicklas wrote:
> >> > You need to debug this somehow. I'd suggest removing the cucumber
> >> > Database cleaner stuff entirely (iirc you need to remove the line that
> >> > requires somthing like cucumber/active_record) and get your own setup
> >> > going. The cucumber way, is very convoluted and error prone, imo.
> >> > Personally I just drop this in my projectshttp://pastie.org/1745020.
> >> > It's a hack suggested originally by Jose Valim which forces
> >> > ActiveRecord to always use the same connection, which will make
> >> > transactions work with Capybara. Not only is it significantly faster,
> >> > you also never have to deal with junk in the database, and you don't
> >> > need DatabaseCleaner at all. It's a win-win, imho. Give it a shot!
> >> > /Jonas
> >> > On Fri, Apr 1, 2011 at 9:49 PM, Larry <i...@stupidtuesday.com> wrote:
> >> >> Hi,
> >> >> My problem still remains, and I hope someone can shed some light on it
> >> >> because I'm dead in the water.
> >> >> I have a simple setup and gem configuration, i.e. nothing too complex
> >> >> or crazy. I have several records that I'd like to display in an
> >> >> "index" action. Again, simple stuff. When I run my Cucumber test
> >> >> without @javascript/selenium it works fine. In fact, when I do a
> >> >> "save_and_open_page" I can see the records on the page.
> >> >> However, when I add the @javascript tag, selenium fires up the
> >> >> browser, but the page is empty. And there's no way I can do any
> >> >> javascript/selenium testing without any database content.
> >> >> Print statements verify the records are being successfully created,
> >> >> but nothing is retrieved from the database. I found a recent RailsCast
> >> >> where Ryan talked about a similar issue, but with RSpec instead of
> >> >> Cucumber. Here is what the corresponding AsciiCast said (http://
> >> >> asciicasts.com/episodes/257-request-specs-and-capybara):
> >> >> =======================================================================
> >> >> This time the first spec fails as the content “paint fence” is missing
> >> >> from the page. The database record that is created isn’t available to
> >> >> the Selenium tests and this is because our specs are using database
> >> >> transactions which aren’t compatible with Selenium. To fix this we can
> >> >> set the config.use_transactional_fixtures setting in the spec_helper
> >> >> file to false.
> >> >> This will get the tests passing again but it will mean that the
> >> >> database records are carried over between specs which we don’t want.
> >> >> To solve this problem we can use a gem called database_cleaner to
> >> >> clean the database between specs.
> >> >> =======================================================================
> >> >> That seems to be what's happening to me, except I'm using Cucumber
> >> >> instead of RSpec. Any help anyone can provide on this subject will be
> >> >> greatly appreciated.
> >> >> Thanks,
> >> >> Larry
> >> >> On Apr 1, 9:03 am, Matt Wynne <m...@mattwynne.net> wrote:
> >> >>> On 1 Apr 2011, at 13:14, Larry wrote:
> >> >>>> P.S. Okay, instead of waiting I decided to do what they suggested:
> >> >>>> take the provided code patch and stick it in my env.rb file. That
> >> >>>> didn't solve the problem. Did you try the fix, and if so, did it work
> >> >>>> for you?
> >> >>> As I said in the comment, I can't vouch for the monkey patch. Try @markus' fork of cucumber-rails instead, that's working for me.
> >> >>>> On Apr 1, 5:04 am, Matt Wynne <m...@mattwynne.net> wrote:
> >> >>>>> This might be a bug in the latest version of cucumber-rails which bit me recently.
> >> >>>>>> Thanks for the reply. I already did that. It's only in my "test"
> >> >>>>>> section (along with capybara and launchy), but that should be the only
> >> >>>>>> place it's needed, right?
> >> >>>>>> It's weird. Basically, I have 5 items in the database and 2 in the
> >> >>>>>> listbox. When the page first loads I should see 3 elements and the
> >> >>>>>> listbox - which I do in development mode and when running cuke tests
> >> >>>>>> without the @javascript tag. (Like I said, I see the 3 elements on the
> >> >>>>>> page when I do a "save_and_open_page", so I know the creation part is
> >> >>>>>> okay.)
> >> >>>>>> But when I run the test with @javascript the browser pops up showing
> >> >>>>>> the listbox... but not the 3 elements. Then it just sits there looking
> >> >>>>>> for the initial 3 elements until it times out, at which point the
> >> >>>>>> browser disappears and the test officially fails.
> >> >>>>>> Any other ideas? (I hope ;-)
> >> >>>>>> Thanks,
> >> >>>>>> Larry
> >> >>>>>> On Mar 31, 7:28 pm, Jonas Nicklas <jonas.nick...@gmail.com> wrote:
> >> >>>>>>> Make sure to add the database_cleaner gem to your gemfile.
> >> >>>>>>> /Jonas
> >> >>>>>>> On Thu, Mar 31, 2011 at 10:51 PM, Larry <i...@stupidtuesday.com> wrote:
> >> >>>>>>>> Hi,
> >> >>>>>>>> I just started using Capybara with JavaScript, so hopefully I'm just
> >> >>>>>>>> making some newbie kind of mistake. (Before I forget: Thanks for great
> >> >>>>>>>> gem!)
> >> >>>>>>>> Don't know if this makes a difference, but... Ubuntu 10.10, Ruby
> >> >>>>>>>> 1.9.2, Rails 3.0.5, FireFox 4.0, Cucumber 0.10.2, Capybara 0.4.1.2,
> >> >>>>>>>> Selenium-Webdriver 0.1.4.
> >> >>>>>>>> * I just Bundle>Updated most of the gems today, so they should be the
> >> >>>>>>>> latest and greatest versions.
> >> >>>>>>>> At the beginning of the test I populate a database with some items. I
> >> >>>>>>>> display a handful of them - along with a listbox - on the initial "GET
> >> >>>>>>>> index" action. When I change the selection in the listbox I use
> >> >>>>>>>> JavaScript (jQuery) to populate the page with a different set of
> >> >>>>>>>> items. Typical vanilla operations.
> >> >>>>>>>> It all works fine in development mode, and when I run my Cucumber
> >> >>>>>>>> tests without the @javascript tag everything works fine until I get to
> >> >>>>>>>> the test for the "new items corresponding to the new listbox
> >> >>>>>>>> selection" - which makes sense because there are no new items because
> >> >>>>>>>> the test is not yet using Selenium/JavaScript.
> >> >>>>>>>> Before I change the listbox selection I test for the presence of the
> >> >>>>>>>> initial items and that test passes. Also, I do a 'save_and_open_page'
> >> >>>>>>>> and I can see that the initial list of items is indeed on the web
> >> >>>>>>>> page, just waiting to be changed according to the new listbox
> >> >>>>>>>> selection.
> First things first: Matt and Jonas - thanks a LOT for helping me (and
> hopefully others) with this issue. I know you must be busy and it
> would've been easier for you to simply wash your hands of this and
> wish me good luck. But you didn't, and I really appreciate that. (Yet
> another thing I love about the Ruby and Rails community!)
> I'll detail what I did for those of you playing along at home (and
> then ask a final question at the end, just to keep you guys on your
> toes ;-)
> 1) I removed the 'gem database_cleaner' statement from my Gemfile, and
> the gem itself from its RVM-managed directory.
> 2) I couldn't find a 'require cucumber/active_record' statement, but I
> did find and comment out the following line:
> <gem-directory>/cucumber-rails-0.4.0/lib/cucumber/rails/hooks.rb :
> 'require 'cucumber/rails/hooks/database_cleaner'
> 3) I created /features/support/local_env.rb and inserted the code
> Jonas pointed me to athttp://pastie.org/1745020
> What the heck, it's short, so here it is in case that link ever gets
> hosed or removed:
> def self.connection
> @@shared_connection || retrieve_connection
> end
> end
> # Forces all threads to share the same connection. This works on
> # Capybara because it starts the web server in a thread.
> ActiveRecord::Base.shared_connection = ActiveRecord::Base.connection
> ==========================================
> And it worked like a charm! Again, thanks a lot, and here's your
> rewards-bonus question! ;-)
> This fixed my Cucumber/Capybara/Selenium problem, but could it ever
> cause problems in development or (more importantly) production mode?
> Do you think it would be a good idea to slap an "if Rails.env.test?"
> statement around the fix?
> Thanks again,
> Larry
> On Apr 1, 4:47 pm, Matt Wynne <m...@mattwynne.net> wrote:
> > Also, for debugging, watch your logs/test.log file very closely during a simple test-case and see if you can decipher anything from that.
> > On 1 Apr 2011, at 21:34, Jonas Nicklas wrote:
> > > You need to debug this somehow. I'd suggest removing the cucumber
> > > Database cleaner stuff entirely (iirc you need to remove the line that
> > > requires somthing like cucumber/active_record) and get your own setup
> > > going. The cucumber way, is very convoluted and error prone, imo.
> > > Personally I just drop this in my projectshttp://pastie.org/1745020.
> > > It's a hack suggested originally by Jose Valim which forces
> > > ActiveRecord to always use the same connection, which will make
> > > transactions work with Capybara. Not only is it significantly faster,
> > > you also never have to deal with junk in the database, and you don't
> > > need DatabaseCleaner at all. It's a win-win, imho. Give it a shot!
> > > /Jonas
> > > On Fri, Apr 1, 2011 at 9:49 PM, Larry <i...@stupidtuesday.com> wrote:
> > >> Hi,
> > >> My problem still remains, and I hope someone can shed some light on it
> > >> because I'm dead in the water.
> > >> I have a simple setup and gem configuration, i.e. nothing too complex
> > >> or crazy. I have several records that I'd like to display in an
> > >> "index" action. Again, simple stuff. When I run my Cucumber test
> > >> without @javascript/selenium it works fine. In fact, when I do a
> > >> "save_and_open_page" I can see the records on the page.
> > >> However, when I add the @javascript tag, selenium fires up the
> > >> browser, but the page is empty. And there's no way I can do any
> > >> javascript/selenium testing without any database content.
> > >> Print statements verify the records are being successfully created,
> > >> but nothing is retrieved from the database. I found a recent RailsCast
> > >> where Ryan talked about a similar issue, but with RSpec instead of
> > >> Cucumber. Here is what the corresponding AsciiCast said (http://
> > >> asciicasts.com/episodes/257-request-specs-and-capybara):
> > >> =======================================================================
> > >> This time the first spec fails as the content “paint fence” is missing
> > >> from the page. The database record that is created isn’t available to
> > >> the Selenium tests and this is because our specs are using database
> > >> transactions which aren’t compatible with Selenium. To fix this we can
> > >> set the config.use_transactional_fixtures setting in the spec_helper
> > >> file to false.
> > >> This will get the tests passing again but it will mean that the
> > >> database records are carried over between specs which we don’t want.
> > >> To solve this problem we can use a gem called database_cleaner to
> > >> clean the database between specs.
> > >> =======================================================================
> > >> That seems to be what's happening to me, except I'm using Cucumber
> > >> instead of RSpec. Any help anyone can provide on this subject will be
> > >> greatly appreciated.
> > >> Thanks,
> > >> Larry
> > >> On Apr 1, 9:03 am, Matt Wynne <m...@mattwynne.net> wrote:
> > >>> On 1 Apr 2011, at 13:14, Larry wrote:
> > >>>> P.S. Okay, instead of waiting I decided to do what they suggested:
> > >>>> take the provided code patch and stick it in my env.rb file. That
> > >>>> didn't solve the problem. Did you try the fix, and if so, did it work
> > >>>> for you?
> > >>> As I said in the comment, I can't vouch for the monkey patch. Try @markus' fork of cucumber-rails instead, that's working for me.
> > >>>> On Apr 1, 5:04 am, Matt Wynne <m...@mattwynne.net> wrote:
> > >>>>> This might be a bug in the latest version of cucumber-rails which bit me recently.
> > >>>>>> Thanks for the reply. I already did that. It's only in my "test"
> > >>>>>> section (along with capybara and launchy), but that should be the only
> > >>>>>> place it's needed, right?
> > >>>>>> It's weird. Basically, I have 5 items in the database and 2 in the
> > >>>>>> listbox. When the page first loads I should see 3 elements and the
> > >>>>>> listbox - which I do in development mode and when running cuke tests
> > >>>>>> without the @javascript tag. (Like I said, I see the 3 elements on the
> > >>>>>> page when I do a "save_and_open_page", so I know the creation part is
> > >>>>>> okay.)
> > >>>>>> But when I run the test with @javascript the browser pops up showing
> > >>>>>> the listbox... but not the 3 elements. Then it just sits there looking
> > >>>>>> for the initial 3 elements until it times out, at which point the
> > >>>>>> browser disappears and the test officially fails.
> > >>>>>> Any other ideas? (I hope ;-)
> > >>>>>> Thanks,
> > >>>>>> Larry
> > >>>>>> On Mar 31, 7:28 pm, Jonas Nicklas <jonas.nick...@gmail.com> wrote:
> > >>>>>>> Make sure to add the database_cleaner gem to your gemfile.
> > >>>>>>> /Jonas
> > >>>>>>> On Thu, Mar 31, 2011 at 10:51 PM, Larry <i...@stupidtuesday.com> wrote:
> > >>>>>>>> Hi,
> > >>>>>>>> I just started using Capybara with JavaScript, so hopefully I'm just
> > >>>>>>>> making some newbie kind of mistake. (Before I forget: Thanks for great
> > >>>>>>>> gem!)
> > >>>>>>>> Don't know if this makes a difference, but... Ubuntu 10.10, Ruby
> > >>>>>>>> 1.9.2, Rails 3.0.5, FireFox 4.0, Cucumber 0.10.2, Capybara 0.4.1.2,
> > >>>>>>>> Selenium-Webdriver 0.1.4.
> > >>>>>>>> * I just Bundle>Updated most of the gems today, so they should be the
> > >>>>>>>> latest and greatest versions.
> > >>>>>>>> At the beginning of the test I populate a database with some items. I
> > >>>>>>>> display a handful of them - along with a listbox - on the initial "GET
> > >>>>>>>> index" action. When I change the selection in the listbox I use
> > >>>>>>>> JavaScript (jQuery) to populate the page with a different set of
> > >>>>>>>> items. Typical vanilla operations.
> > >>>>>>>> It all works fine in development mode, and when I run my Cucumber
> > >>>>>>>> tests without the @javascript tag everything works fine until I get to
> > >>>>>>>> the test for the "new items corresponding to the new listbox
> > >>>>>>>> selection" - which makes sense because there are no new items because
> > >>>>>>>> the test is not yet using Selenium/JavaScript.
> > >>>>>>>> Before I change the listbox selection I test for the presence of the
> > >>>>>>>> initial items and that test passes. Also, I do a 'save_and_open_page'
> > >>>>>>>> and I can see that the initial list of items is indeed on the web
> > >>>>>>>> page, just waiting to be changed according to the new listbox
> > >>>>>>>> selection.
> > >>>>>>>> This leads me to believe that all of the plumbing is hooked up
> > >>>>>>>> correctly.
> > >>>>>>>> Now, when I put the @javascript tag before my "Scenario:" statement,
> > >>>>>>>> Capybara dutifully fires up the browser, but there are no initial
> > >>>>>>>> items on the web page. The listbox is there and it contains the right
> > >>>>>>>> choices, but my first "are the initial items on the page" test (that
> > >>>>>>>> used to pass) now fails because there's nothing there.
> > >>>>>>>> I increased the 'Capybara.default_wait_time' but that didn't make a
I ran some more tests and noticed that my database wasn't getting
cleaned out between runs. I was under the impression that transactions
were being used, which meant your fix allowed access to the data
because it used the same connection.
But, like I said, data remained in the database. When I hooked all of
the database-cleaner plumbing back up everything worked.
Does this make sense to you?
Sorry to keep this issue alive. If it makes sense and a quick
explanation suffices, fine. If not, I'm perfectly willing to just
accept the fact that it works and move on - something I think we all
do in this DSL and automagical world of Ruby and Rails.
-- Larry
On Apr 4, 10:24 am, Jonas Nicklas <jonas.nick...@gmail.com> wrote:
> Yes, you should definitely not be loading that code in production. In
> most cases it won't make a difference, but if you ever move to a
> threaded environment, you'll be in a world of pain with a tricky to
> debug issue. Save yourself the trouble and only load it in the test
> env (I usually put it in features/support/shared_connection.rb or
> something)
> /Jonas
> On Mon, Apr 4, 2011 at 4:16 PM, Larry <i...@stupidtuesday.com> wrote:
> > YES!!!
> > First things first: Matt and Jonas - thanks a LOT for helping me (and
> > hopefully others) with this issue. I know you must be busy and it
> > would've been easier for you to simply wash your hands of this and
> > wish me good luck. But you didn't, and I really appreciate that. (Yet
> > another thing I love about the Ruby and Rails community!)
> > I'll detail what I did for those of you playing along at home (and
> > then ask a final question at the end, just to keep you guys on your
> > toes ;-)
> > 1) I removed the 'gem database_cleaner' statement from my Gemfile, and
> > the gem itself from its RVM-managed directory.
> > 2) I couldn't find a 'require cucumber/active_record' statement, but I
> > did find and comment out the following line:
> > <gem-directory>/cucumber-rails-0.4.0/lib/cucumber/rails/hooks.rb :
> > 'require 'cucumber/rails/hooks/database_cleaner'
> > 3) I created /features/support/local_env.rb and inserted the code
> > Jonas pointed me to athttp://pastie.org/1745020
> > What the heck, it's short, so here it is in case that link ever gets
> > hosed or removed:
> > def self.connection
> > @@shared_connection || retrieve_connection
> > end
> > end
> > # Forces all threads to share the same connection. This works on
> > # Capybara because it starts the web server in a thread.
> > ActiveRecord::Base.shared_connection = ActiveRecord::Base.connection
> > ==========================================
> > And it worked like a charm! Again, thanks a lot, and here's your
> > rewards-bonus question! ;-)
> > This fixed my Cucumber/Capybara/Selenium problem, but could it ever
> > cause problems in development or (more importantly) production mode?
> > Do you think it would be a good idea to slap an "if Rails.env.test?"
> > statement around the fix?
> > Thanks again,
> > Larry
> > On Apr 1, 4:47 pm, Matt Wynne <m...@mattwynne.net> wrote:
> >> Also, for debugging, watch your logs/test.log file very closely during a simple test-case and see if you can decipher anything from that.
> >> On 1 Apr 2011, at 21:34, Jonas Nicklas wrote:
> >> > You need to debug this somehow. I'd suggest removing the cucumber
> >> > Database cleaner stuff entirely (iirc you need to remove the line that
> >> > requires somthing like cucumber/active_record) and get your own setup
> >> > going. The cucumber way, is very convoluted and error prone, imo.
> >> > Personally I just drop this in my projectshttp://pastie.org/1745020.
> >> > It's a hack suggested originally by Jose Valim which forces
> >> > ActiveRecord to always use the same connection, which will make
> >> > transactions work with Capybara. Not only is it significantly faster,
> >> > you also never have to deal with junk in the database, and you don't
> >> > need DatabaseCleaner at all. It's a win-win, imho. Give it a shot!
> >> > /Jonas
> >> > On Fri, Apr 1, 2011 at 9:49 PM, Larry <i...@stupidtuesday.com> wrote:
> >> >> Hi,
> >> >> My problem still remains, and I hope someone can shed some light on it
> >> >> because I'm dead in the water.
> >> >> I have a simple setup and gem configuration, i.e. nothing too complex
> >> >> or crazy. I have several records that I'd like to display in an
> >> >> "index" action. Again, simple stuff. When I run my Cucumber test
> >> >> without @javascript/selenium it works fine. In fact, when I do a
> >> >> "save_and_open_page" I can see the records on the page.
> >> >> However, when I add the @javascript tag, selenium fires up the
> >> >> browser, but the page is empty. And there's no way I can do any
> >> >> javascript/selenium testing without any database content.
> >> >> Print statements verify the records are being successfully created,
> >> >> but nothing is retrieved from the database. I found a recent RailsCast
> >> >> where Ryan talked about a similar issue, but with RSpec instead of
> >> >> Cucumber. Here is what the corresponding AsciiCast said (http://
> >> >> asciicasts.com/episodes/257-request-specs-and-capybara):
> >> >> =======================================================================
> >> >> This time the first spec fails as the content “paint fence” is missing
> >> >> from the page. The database record that is created isn’t available to
> >> >> the Selenium tests and this is because our specs are using database
> >> >> transactions which aren’t compatible with Selenium. To fix this we can
> >> >> set the config.use_transactional_fixtures setting in the spec_helper
> >> >> file to false.
> >> >> This will get the tests passing again but it will mean that the
> >> >> database records are carried over between specs which we don’t want.
> >> >> To solve this problem we can use a gem called database_cleaner to
> >> >> clean the database between specs.
> >> >> =======================================================================
> >> >> That seems to be what's happening to me, except I'm using Cucumber
> >> >> instead of RSpec. Any help anyone can provide on this subject will be
> >> >> greatly appreciated.
> >> >> Thanks,
> >> >> Larry
> >> >> On Apr 1, 9:03 am, Matt Wynne <m...@mattwynne.net> wrote:
> >> >>> On 1 Apr 2011, at 13:14, Larry wrote:
> >> >>>> P.S. Okay, instead of waiting I decided to do what they suggested:
> >> >>>> take the provided code patch and stick it in my env.rb file. That
> >> >>>> didn't solve the problem. Did you try the fix, and if so, did it work
> >> >>>> for you?
> >> >>> As I said in the comment, I can't vouch for the monkey patch. Try @markus' fork of cucumber-rails instead, that's working for me.
> >> >>>> On Apr 1, 5:04 am, Matt Wynne <m...@mattwynne.net> wrote:
> >> >>>>> This might be a bug in the latest version of cucumber-rails which bit me recently.
> >> >>>>>> Thanks for the reply. I already did that. It's only in my "test"
> >> >>>>>> section (along with capybara and launchy), but that should be the only
> >> >>>>>> place it's needed, right?
> >> >>>>>> It's weird. Basically, I have 5 items in the database and 2 in the
> >> >>>>>> listbox. When the page first loads I should see 3 elements and the
> >> >>>>>> listbox - which I do in development mode and when running cuke tests
> >> >>>>>> without the @javascript tag. (Like I said, I see the 3 elements on the
> >> >>>>>> page when I do a "save_and_open_page", so I know the creation part is
> >> >>>>>> okay.)
> >> >>>>>> But when I run the test with @javascript the browser pops up showing
> >> >>>>>> the listbox... but not the 3 elements. Then it just sits there looking
> >> >>>>>> for the initial 3 elements until it times out, at which point the
> >> >>>>>> browser disappears and the test officially fails.
> >> >>>>>> Any other ideas? (I hope ;-)
> >> >>>>>> Thanks,
> >> >>>>>> Larry
> >> >>>>>> On Mar 31, 7:28 pm, Jonas Nicklas <jonas.nick...@gmail.com> wrote:
> >> >>>>>>> Make sure to add the database_cleaner gem to your gemfile.
> >> >>>>>>> /Jonas
> >> >>>>>>> On Thu, Mar 31, 2011 at 10:51 PM, Larry <i...@stupidtuesday.com> wrote:
> >> >>>>>>>> Hi,
> >> >>>>>>>> I just started using Capybara with JavaScript, so hopefully I'm just
> >> >>>>>>>> making some newbie kind of mistake. (Before I forget: Thanks for great
> >> >>>>>>>> gem!)
> >> >>>>>>>> Don't know if this makes a difference, but... Ubuntu 10.10, Ruby
> >> >>>>>>>> 1.9.2, Rails 3.0.5, FireFox 4.0, Cucumber 0.10.2, Capybara 0.4.1.2,
> >> >>>>>>>> Selenium-Webdriver 0.1.4.
> >> >>>>>>>> * I just Bundle>Updated most of the gems today, so they should be the
> >> >>>>>>>> latest and greatest versions.
> >> >>>>>>>> At the beginning of the test I populate a database with some items. I
> >> >>>>>>>> display a handful of them - along with a listbox - on the initial "GET
> >> >>>>>>>> index" action. When I change the selection in the listbox I use
> >> >>>>>>>> JavaScript (jQuery) to populate the page with a different set of
> >> >>>>>>>> items. Typical vanilla operations.
> >> >>>>>>>> It all works fine in development mode, and when I run my Cucumber
> >> >>>>>>>> tests
On Mon, Apr 4, 2011 at 4:16 PM, Larry <i...@stupidtuesday.com> wrote: > 3) I created /features/support/local_env.rb and inserted the code > Jonas pointed me to at http://pastie.org/1745020
If I understand the purpose of that code correctly, you could also use database_cleaner's truncation mode, right? (Though it might be a little slower, depending on the size of your test DB.)
> This fixed my Cucumber/Capybara/Selenium problem, but could it ever > cause problems in development or (more importantly) production mode? > Do you think it would be a good idea to slap an "if Rails.env.test?" > statement around the fix?
As Jonas said, you shouldn't be doing this in production, but since it's under features/support, it's only ever loaded by Cucumber, so there's no need to check Rails.env.test?.
Thanks for chiming in. I wanted to test your theory and you are right:
When I removed the fix Jonas supplied and changed the
"DatabaseCleaner.strategy" from ":transaction" to ":truncation" in
"features/support/env.rb" everything worked.
I still don't fully understand all of this stuff, but I now have 2
solutions which will hopefully be helpful to others.
Thanks!
-- Larry
On Apr 4, 11:07 am, Jo Liss <jolis...@gmail.com> wrote:
> On Mon, Apr 4, 2011 at 4:16 PM, Larry <i...@stupidtuesday.com> wrote:
> > 3) I created /features/support/local_env.rb and inserted the code
> > Jonas pointed me to athttp://pastie.org/1745020
> If I understand the purpose of that code correctly, you could also use
> database_cleaner's truncation mode, right? (Though it might be a
> little slower, depending on the size of your test DB.)
> > This fixed my Cucumber/Capybara/Selenium problem, but could it ever
> > cause problems in development or (more importantly) production mode?
> > Do you think it would be a good idea to slap an "if Rails.env.test?"
> > statement around the fix?
> As Jonas said, you shouldn't be doing this in production, but since
> it's under features/support, it's only ever loaded by Cucumber, so
> there's no need to check Rails.env.test?.
On Fri, Apr 1, 2011 at 10:34 PM, Jonas Nicklas <jonas.nick...@gmail.com> wrote: > Personally I just drop this in my projects http://pastie.org/1745020. > It's a hack suggested originally by Jose Valim which forces > ActiveRecord to always use the same connection, which will make > transactions work with Capybara. Not only is it significantly faster, > you also never have to deal with junk in the database, and you don't > need DatabaseCleaner at all.
- you can use transactions use Rack::Test, but - you cannot use them with any "external" tester (like Selenium or HtmlUnit), so you have to use DatabaseCleaner with the truncation method?
(I'm using DatabaseCleaner with :truncation as well to stop my Selenium tests from breaking, but I'm not sure if that problem is universal.)
Yes, I would agree with Jen-Mei's assessment and your summary because
that's exactly what happened to me. (So I guess you have to figure out
how much trust you want to put in a Sample Size of 2 :-)
-- Larry
On Apr 4, 11:38 am, Jo Liss <jolis...@gmail.com> wrote:
> On Fri, Apr 1, 2011 at 10:34 PM, Jonas Nicklas <jonas.nick...@gmail.com> wrote:
> > Personally I just drop this in my projectshttp://pastie.org/1745020.
> > It's a hack suggested originally by Jose Valim which forces
> > ActiveRecord to always use the same connection, which will make
> > transactions work with Capybara. Not only is it significantly faster,
> > you also never have to deal with junk in the database, and you don't
> > need DatabaseCleaner at all.
> - you can use transactions use Rack::Test, but
> - you cannot use them with any "external" tester (like Selenium or
> HtmlUnit), so you have to use DatabaseCleaner with the truncation
> method?
> (I'm using DatabaseCleaner with :truncation as well to stop my
> Selenium tests from breaking, but I'm not sure if that problem is
> universal.)
Just to clear this up a bit and explain the how an why a bit.
When Capybara runs under rack-test, everything happens in the same thread of the same process. Capybara runs your stuff directly agains your Rails app. What this means is that if you open a transaction in cucumber, that same transaction is used within your Rails app, so if you create a database record in Cucumber, it will show up in your Rails app.
What happens under Selenium is this: Capybara starts up your Rails app using a webserver (usually webrick or thin) in a *separate thread* of the *same process*. ActiveRecord assumes that different threads are used to handle concurrent requests, so it uses separate connections, and thus separate transactions for each thread. What this means is that if a record is created in Cucumber, that record is created in a different transaction than the Rails app is running under, which means it *won't* show up in the app.
Makes sense?
This leaves us with three possible solutions:
1. Switch off transactions entirely, truncate (empty out) the database after each test 2. Switch off transactions only for those tests that use Selenium, truncate the DB after those. 3. Make sure transactions are switched *on* and force Rails to use the same transaction for all threads
If you just set up DatabaseCleaner with :truncation mode, number 1 will happen. This should do the job, but it's pretty slow. Also transactions are nice, since there's less risk of crap data remaining in your DB. Number 2 is what cucumber does out of the box. It works, but it's kind of convoluted, and has a tendency to break every now and then.
Number 3 is what José's hack is all about. The consequence of this, is that if you use 3, transactions need to be switched *on*. You do not need DatabaseCleaner for that, just set:
On Mon, Apr 4, 2011 at 5:25 PM, Larry <i...@stupidtuesday.com> wrote: > Hi Jo,
> Thanks for chiming in. I wanted to test your theory and you are right: > When I removed the fix Jonas supplied and changed the > "DatabaseCleaner.strategy" from ":transaction" to ":truncation" in > "features/support/env.rb" everything worked.
> I still don't fully understand all of this stuff, but I now have 2 > solutions which will hopefully be helpful to others.
> Thanks!
> -- Larry
> On Apr 4, 11:07 am, Jo Liss <jolis...@gmail.com> wrote: >> On Mon, Apr 4, 2011 at 4:16 PM, Larry <i...@stupidtuesday.com> wrote: >> > 3) I created /features/support/local_env.rb and inserted the code >> > Jonas pointed me to athttp://pastie.org/1745020
>> If I understand the purpose of that code correctly, you could also use >> database_cleaner's truncation mode, right? (Though it might be a >> little slower, depending on the size of your test DB.)
>> > This fixed my Cucumber/Capybara/Selenium problem, but could it ever >> > cause problems in development or (more importantly) production mode? >> > Do you think it would be a good idea to slap an "if Rails.env.test?" >> > statement around the fix?
>> As Jonas said, you shouldn't be doing this in production, but since >> it's under features/support, it's only ever loaded by Cucumber, so >> there's no need to check Rails.env.test?.
It certainly does clear up the confusion, Jonas. And thanks for taking
the time to write that excellent synopsis. It always helps to know
what's going on underneath the covers, and the scenarios and reasons
you described are usually not explained in whatever Rails book you're
reading at the time; they usually just say that transactions are run
under the scope of a connection and leave it at that. Which is fine,
if you know what that actually *means*, and not so fine if you don't.
And now I - and others who will read this - do! :-)
Thanks again,
Larry
On Apr 4, 6:15 pm, Jonas Nicklas <jonas.nick...@gmail.com> wrote:
> Just to clear this up a bit and explain the how an why a bit.
> When Capybara runs under rack-test, everything happens in the same
> thread of the same process. Capybara runs your stuff directly agains
> your Rails app. What this means is that if you open a transaction in
> cucumber, that same transaction is used within your Rails app, so if
> you create a database record in Cucumber, it will show up in your
> Rails app.
> What happens under Selenium is this: Capybara starts up your Rails app
> using a webserver (usually webrick or thin) in a *separate thread* of
> the *same process*. ActiveRecord assumes that different threads are
> used to handle concurrent requests, so it uses separate connections,
> and thus separate transactions for each thread. What this means is
> that if a record is created in Cucumber, that record is created in a
> different transaction than the Rails app is running under, which means
> it *won't* show up in the app.
> Makes sense?
> This leaves us with three possible solutions:
> 1. Switch off transactions entirely, truncate (empty out) the database
> after each test
> 2. Switch off transactions only for those tests that use Selenium,
> truncate the DB after those.
> 3. Make sure transactions are switched *on* and force Rails to use the
> same transaction for all threads
> If you just set up DatabaseCleaner with :truncation mode, number 1
> will happen. This should do the job, but it's pretty slow. Also
> transactions are nice, since there's less risk of crap data remaining
> in your DB. Number 2 is what cucumber does out of the box. It works,
> but it's kind of convoluted, and has a tendency to break every now and
> then.
> Number 3 is what José's hack is all about. The consequence of this, is
> that if you use 3, transactions need to be switched *on*. You do not
> need DatabaseCleaner for that, just set:
> On Mon, Apr 4, 2011 at 5:25 PM, Larry <i...@stupidtuesday.com> wrote:
> > Hi Jo,
> > Thanks for chiming in. I wanted to test your theory and you are right:
> > When I removed the fix Jonas supplied and changed the
> > "DatabaseCleaner.strategy" from ":transaction" to ":truncation" in
> > "features/support/env.rb" everything worked.
> > I still don't fully understand all of this stuff, but I now have 2
> > solutions which will hopefully be helpful to others.
> > Thanks!
> > -- Larry
> > On Apr 4, 11:07 am, Jo Liss <jolis...@gmail.com> wrote:
> >> On Mon, Apr 4, 2011 at 4:16 PM, Larry <i...@stupidtuesday.com> wrote:
> >> > 3) I created /features/support/local_env.rb and inserted the code
> >> > Jonas pointed me to athttp://pastie.org/1745020
> >> If I understand the purpose of that code correctly, you could also use
> >> database_cleaner's truncation mode, right? (Though it might be a
> >> little slower, depending on the size of your test DB.)
> >> > This fixed my Cucumber/Capybara/Selenium problem, but could it ever
> >> > cause problems in development or (more importantly) production mode?
> >> > Do you think it would be a good idea to slap an "if Rails.env.test?"
> >> > statement around the fix?
> >> As Jonas said, you shouldn't be doing this in production, but since
> >> it's under features/support, it's only ever loaded by Cucumber, so
> >> there's no need to check Rails.env.test?.
Awww, man... sorry to be a pain, but what you suggested didn't work
(at least for me).
The last post by Jonas made a lot of sense, and it seemed that option
#3 was the best choice. So I removed my database-cleaner code and put
the patch code (to force using the same connection) back in my
features/support/local_env.rb - along with the following statement:
Cucumber::Rails::World.use_transactional_fixtures = true
But records remain in the database after the tests have run. And
(obviously) they keep building up with each run.
I put print statements in 'local_env.rb' to make sure that
"use_transactional_fixtures" was being set to true and that the patch
code was being run - which was verified. I also put print statements
in my tests to make sure that "use_transactional_fixtures" wasn't
somehow getting set back to false - it wasn't.
So everything seems to be in order. I also figure the patch must be
working because if it wasn't I wouldn't be seeing any data on my web
page. But I am, so I assume the same connection/transaction is being
used.
But the data remains in the database.
Any ideas?
Thanks,
Larry
On Apr 5, 7:11 am, Larry <i...@stupidtuesday.com> wrote:
> It certainly does clear up the confusion, Jonas. And thanks for taking
> the time to write that excellent synopsis. It always helps to know
> what's going on underneath the covers, and the scenarios and reasons
> you described are usually not explained in whatever Rails book you're
> reading at the time; they usually just say that transactions are run
> under the scope of a connection and leave it at that. Which is fine,
> if you know what that actually *means*, and not so fine if you don't.
> And now I - and others who will read this - do! :-)
> Thanks again,
> Larry
> On Apr 4, 6:15 pm, Jonas Nicklas <jonas.nick...@gmail.com> wrote:
> > Just to clear this up a bit and explain the how an why a bit.
> > When Capybara runs under rack-test, everything happens in the same
> > thread of the same process. Capybara runs your stuff directly agains
> > your Rails app. What this means is that if you open a transaction in
> > cucumber, that same transaction is used within your Rails app, so if
> > you create a database record in Cucumber, it will show up in your
> > Rails app.
> > What happens under Selenium is this: Capybara starts up your Rails app
> > using a webserver (usually webrick or thin) in a *separate thread* of
> > the *same process*. ActiveRecord assumes that different threads are
> > used to handle concurrent requests, so it uses separate connections,
> > and thus separate transactions for each thread. What this means is
> > that if a record is created in Cucumber, that record is created in a
> > different transaction than the Rails app is running under, which means
> > it *won't* show up in the app.
> > Makes sense?
> > This leaves us with three possible solutions:
> > 1. Switch off transactions entirely, truncate (empty out) the database
> > after each test
> > 2. Switch off transactions only for those tests that use Selenium,
> > truncate the DB after those.
> > 3. Make sure transactions are switched *on* and force Rails to use the
> > same transaction for all threads
> > If you just set up DatabaseCleaner with :truncation mode, number 1
> > will happen. This should do the job, but it's pretty slow. Also
> > transactions are nice, since there's less risk of crap data remaining
> > in your DB. Number 2 is what cucumber does out of the box. It works,
> > but it's kind of convoluted, and has a tendency to break every now and
> > then.
> > Number 3 is what José's hack is all about. The consequence of this, is
> > that if you use 3, transactions need to be switched *on*. You do not
> > need DatabaseCleaner for that, just set:
> > On Mon, Apr 4, 2011 at 5:25 PM, Larry <i...@stupidtuesday.com> wrote:
> > > Hi Jo,
> > > Thanks for chiming in. I wanted to test your theory and you are right:
> > > When I removed the fix Jonas supplied and changed the
> > > "DatabaseCleaner.strategy" from ":transaction" to ":truncation" in
> > > "features/support/env.rb" everything worked.
> > > I still don't fully understand all of this stuff, but I now have 2
> > > solutions which will hopefully be helpful to others.
> > > Thanks!
> > > -- Larry
> > > On Apr 4, 11:07 am, Jo Liss <jolis...@gmail.com> wrote:
> > >> On Mon, Apr 4, 2011 at 4:16 PM, Larry <i...@stupidtuesday.com> wrote:
> > >> > 3) I created /features/support/local_env.rb and inserted the code
> > >> > Jonas pointed me to athttp://pastie.org/1745020
> > >> If I understand the purpose of that code correctly, you could also use
> > >> database_cleaner's truncation mode, right? (Though it might be a
> > >> little slower, depending on the size of your test DB.)
> > >> > This fixed my Cucumber/Capybara/Selenium problem, but could it ever
> > >> > cause problems in development or (more importantly) production mode?
> > >> > Do you think it would be a good idea to slap an "if Rails.env.test?"
> > >> > statement around the fix?
> > >> As Jonas said, you shouldn't be doing this in production, but since
> > >> it's under features/support, it's only ever loaded by Cucumber, so
> > >> there's no need to check Rails.env.test?.
> Awww, man... sorry to be a pain, but what you suggested didn't work > (at least for me).
> The last post by Jonas made a lot of sense, and it seemed that option > #3 was the best choice. So I removed my database-cleaner code and put > the patch code (to force using the same connection) back in my > features/support/local_env.rb - along with the following statement: > Cucumber::Rails::World.use_transactional_fixtures = true
> But records remain in the database after the tests have run. And > (obviously) they keep building up with each run.
> I put print statements in 'local_env.rb' to make sure that > "use_transactional_fixtures" was being set to true and that the patch > code was being run - which was verified. I also put print statements > in my tests to make sure that "use_transactional_fixtures" wasn't > somehow getting set back to false - it wasn't.
> So everything seems to be in order. I also figure the patch must be > working because if it wasn't I wouldn't be seeing any data on my web > page. But I am, so I assume the same connection/transaction is being > used.
> But the data remains in the database.
> Any ideas?
No more ideas, but I have some advice.
Take a break and come back to it fresh. You have all the information you need to solve the problem now. Give your brain a chance to process it all :)
> On Apr 5, 7:11 am, Larry <i...@stupidtuesday.com> wrote: >> It certainly does clear up the confusion, Jonas. And thanks for taking >> the time to write that excellent synopsis. It always helps to know >> what's going on underneath the covers, and the scenarios and reasons >> you described are usually not explained in whatever Rails book you're >> reading at the time; they usually just say that transactions are run >> under the scope of a connection and leave it at that. Which is fine, >> if you know what that actually *means*, and not so fine if you don't.
>> And now I - and others who will read this - do! :-)
>> Thanks again, >> Larry
>> On Apr 4, 6:15 pm, Jonas Nicklas <jonas.nick...@gmail.com> wrote:
>>> Just to clear this up a bit and explain the how an why a bit.
>>> When Capybara runs under rack-test, everything happens in the same >>> thread of the same process. Capybara runs your stuff directly agains >>> your Rails app. What this means is that if you open a transaction in >>> cucumber, that same transaction is used within your Rails app, so if >>> you create a database record in Cucumber, it will show up in your >>> Rails app.
>>> What happens under Selenium is this: Capybara starts up your Rails app >>> using a webserver (usually webrick or thin) in a *separate thread* of >>> the *same process*. ActiveRecord assumes that different threads are >>> used to handle concurrent requests, so it uses separate connections, >>> and thus separate transactions for each thread. What this means is >>> that if a record is created in Cucumber, that record is created in a >>> different transaction than the Rails app is running under, which means >>> it *won't* show up in the app.
>>> Makes sense?
>>> This leaves us with three possible solutions:
>>> 1. Switch off transactions entirely, truncate (empty out) the database >>> after each test >>> 2. Switch off transactions only for those tests that use Selenium, >>> truncate the DB after those. >>> 3. Make sure transactions are switched *on* and force Rails to use the >>> same transaction for all threads
>>> If you just set up DatabaseCleaner with :truncation mode, number 1 >>> will happen. This should do the job, but it's pretty slow. Also >>> transactions are nice, since there's less risk of crap data remaining >>> in your DB. Number 2 is what cucumber does out of the box. It works, >>> but it's kind of convoluted, and has a tendency to break every now and >>> then.
>>> Number 3 is what José's hack is all about. The consequence of this, is >>> that if you use 3, transactions need to be switched *on*. You do not >>> need DatabaseCleaner for that, just set:
>>> On Mon, Apr 4, 2011 at 5:25 PM, Larry <i...@stupidtuesday.com> wrote: >>>> Hi Jo,
>>>> Thanks for chiming in. I wanted to test your theory and you are right: >>>> When I removed the fix Jonas supplied and changed the >>>> "DatabaseCleaner.strategy" from ":transaction" to ":truncation" in >>>> "features/support/env.rb" everything worked.
>>>> I still don't fully understand all of this stuff, but I now have 2 >>>> solutions which will hopefully be helpful to others.
>>>> Thanks!
>>>> -- Larry
>>>> On Apr 4, 11:07 am, Jo Liss <jolis...@gmail.com> wrote: >>>>> On Mon, Apr 4, 2011 at 4:16 PM, Larry <i...@stupidtuesday.com> wrote: >>>>>> 3) I created /features/support/local_env.rb and inserted the code >>>>>> Jonas pointed me to athttp://pastie.org/1745020
>>>>> If I understand the purpose of that code correctly, you could also use >>>>> database_cleaner's truncation mode, right? (Though it might be a >>>>> little slower, depending on the size of your test DB.)
>>>>>> This fixed my Cucumber/Capybara/Selenium problem, but could it ever >>>>>> cause problems in development or (more importantly) production mode? >>>>>> Do you think it would be a good idea to slap an "if Rails.env.test?" >>>>>> statement around the fix?
>>>>> As Jonas said, you shouldn't be doing this in production, but since >>>>> it's under features/support, it's only ever loaded by Cucumber, so >>>>> there's no need to check Rails.env.test?.
When I read it first thing this morning I realized you were right and
recognized the importance of your advice not just for this issue, but
any vexing problem you're having at the time. (It also made me feel
better :-)
To make matters worse, I was wrestling with another issue at the same
time, and found my brain mixing and mashing together all of the
different aspects of both problems - thus compounding the confusion.
Anyway, I separated the two and planned on attacking them one at a
time. This one was first and it turned out to be pretty easy - but
only because the Cucumber folks released a new version of the cucumber-
rails gem. I installed that and re-ran the generator and lo and
behold... it worked!
So many thanks to you guys and the Cucumber folks (if they are
following this) - all of your great work and help is much appreciated!
-- Larry
On Apr 5, 4:00 pm, Matt Wynne <m...@mattwynne.net> wrote:
> > Awww, man... sorry to be a pain, but what you suggested didn't work
> > (at least for me).
> > The last post by Jonas made a lot of sense, and it seemed that option
> > #3 was the best choice. So I removed my database-cleaner code and put
> > the patch code (to force using the same connection) back in my
> > features/support/local_env.rb - along with the following statement:
> > Cucumber::Rails::World.use_transactional_fixtures = true
> > But records remain in the database after the tests have run. And
> > (obviously) they keep building up with each run.
> > I put print statements in 'local_env.rb' to make sure that
> > "use_transactional_fixtures" was being set to true and that the patch
> > code was being run - which was verified. I also put print statements
> > in my tests to make sure that "use_transactional_fixtures" wasn't
> > somehow getting set back to false - it wasn't.
> > So everything seems to be in order. I also figure the patch must be
> > working because if it wasn't I wouldn't be seeing any data on my web
> > page. But I am, so I assume the same connection/transaction is being
> > used.
> > But the data remains in the database.
> > Any ideas?
> No more ideas, but I have some advice.
> Take a break and come back to it fresh. You have all the information you need to solve the problem now. Give your brain a chance to process it all :)
> > Thanks,
> > Larry
> > On Apr 5, 7:11 am, Larry <i...@stupidtuesday.com> wrote:
> >> It certainly does clear up the confusion, Jonas. And thanks for taking
> >> the time to write that excellent synopsis. It always helps to know
> >> what's going on underneath the covers, and the scenarios and reasons
> >> you described are usually not explained in whatever Rails book you're
> >> reading at the time; they usually just say that transactions are run
> >> under the scope of a connection and leave it at that. Which is fine,
> >> if you know what that actually *means*, and not so fine if you don't.
> >> And now I - and others who will read this - do! :-)
> >> Thanks again,
> >> Larry
> >> On Apr 4, 6:15 pm, Jonas Nicklas <jonas.nick...@gmail.com> wrote:
> >>> Just to clear this up a bit and explain the how an why a bit.
> >>> When Capybara runs under rack-test, everything happens in the same
> >>> thread of the same process. Capybara runs your stuff directly agains
> >>> your Rails app. What this means is that if you open a transaction in
> >>> cucumber, that same transaction is used within your Rails app, so if
> >>> you create a database record in Cucumber, it will show up in your
> >>> Rails app.
> >>> What happens under Selenium is this: Capybara starts up your Rails app
> >>> using a webserver (usually webrick or thin) in a *separate thread* of
> >>> the *same process*. ActiveRecord assumes that different threads are
> >>> used to handle concurrent requests, so it uses separate connections,
> >>> and thus separate transactions for each thread. What this means is
> >>> that if a record is created in Cucumber, that record is created in a
> >>> different transaction than the Rails app is running under, which means
> >>> it *won't* show up in the app.
> >>> Makes sense?
> >>> This leaves us with three possible solutions:
> >>> 1. Switch off transactions entirely, truncate (empty out) the database
> >>> after each test
> >>> 2. Switch off transactions only for those tests that use Selenium,
> >>> truncate the DB after those.
> >>> 3. Make sure transactions are switched *on* and force Rails to use the
> >>> same transaction for all threads
> >>> If you just set up DatabaseCleaner with :truncation mode, number 1
> >>> will happen. This should do the job, but it's pretty slow. Also
> >>> transactions are nice, since there's less risk of crap data remaining
> >>> in your DB. Number 2 is what cucumber does out of the box. It works,
> >>> but it's kind of convoluted, and has a tendency to break every now and
> >>> then.
> >>> Number 3 is what José's hack is all about. The consequence of this, is
> >>> that if you use 3, transactions need to be switched *on*. You do not
> >>> need DatabaseCleaner for that, just set:
> >>> On Mon, Apr 4, 2011 at 5:25 PM, Larry <i...@stupidtuesday.com> wrote:
> >>>> Hi Jo,
> >>>> Thanks for chiming in. I wanted to test your theory and you are right:
> >>>> When I removed the fix Jonas supplied and changed the
> >>>> "DatabaseCleaner.strategy" from ":transaction" to ":truncation" in
> >>>> "features/support/env.rb" everything worked.
> >>>> I still don't fully understand all of this stuff, but I now have 2
> >>>> solutions which will hopefully be helpful to others.
> >>>> Thanks!
> >>>> -- Larry
> >>>> On Apr 4, 11:07 am, Jo Liss <jolis...@gmail.com> wrote:
> >>>>> On Mon, Apr 4, 2011 at 4:16 PM, Larry <i...@stupidtuesday.com> wrote:
> >>>>>> 3) I created /features/support/local_env.rb and inserted the code
> >>>>>> Jonas pointed me to athttp://pastie.org/1745020
> >>>>> If I understand the purpose of that code correctly, you could also use
> >>>>> database_cleaner's truncation mode, right? (Though it might be a
> >>>>> little slower, depending on the size of your test DB.)
> >>>>>> This fixed my Cucumber/Capybara/Selenium problem, but could it ever
> >>>>>> cause problems in development or (more importantly) production mode?
> >>>>>> Do you think it would be a good idea to slap an "if Rails.env.test?"
> >>>>>> statement around the fix?
> >>>>> As Jonas said, you shouldn't be doing this in production, but since
> >>>>> it's under features/support, it's only ever loaded by Cucumber, so
> >>>>> there's no need to check Rails.env.test?.
Which gem versions do you get this trick to work with cucumber and selenium? For me it works with rspec/capybara, but not for cucumber (in the same project).
From the logs it appears that it isn't enabling transactional features with cucumber. If I put database_cleaner back in the tests pass. Has the config attribute to turn them on/off been removed? Or is it still working for you?
so we're pretty close on that. (Although one point-release here or
there can make a world of difference ;-)
I also have database_cleaner (0.6.7)
Here's where we do differ, though, so maybe this will solve your
problem:
In my support/env.rb I have the following (which I believe is what you
get when you run the cucumber:install generator after installing a new
version of the cucumber gem):
begin
DatabaseCleaner.strategy = :transaction
rescue NameError
raise "You need to add database_cleaner to your Gemfile (in
the :test group) if you wish to use it."
end
Hope this helps,
Larry
On Jul 7, 11:46 am, nruth <nick.rutherf...@gmail.com> wrote:
> Which gem versions do you get this trick to work with cucumber and selenium?
> For me it works with rspec/capybara, but not for cucumber (in the same
> project).
> From the logs it appears that it isn't enabling transactional features with
> cucumber. If I put database_cleaner back in the tests pass.
> Has the config attribute to turn them on/off been removed? Or is it still
> working for you?
