Skip to content

Run integration tests through the app's executor#24608

Closed
sgrif wants to merge 1 commit into
rails:masterfrom
sgrif:sg-integration-testing
Closed

Run integration tests through the app's executor#24608
sgrif wants to merge 1 commit into
rails:masterfrom
sgrif:sg-integration-testing

Conversation

@sgrif

@sgrif sgrif commented Apr 18, 2016

Copy link
Copy Markdown
Contributor

This ensures that the "unit of computation" is an entire test, instead
of the request. This allows us to skip, for example, connection pooling.
This ensures that the same connection is used for the entire test.

We should arguably do this for all tests, but this level is the only
place that we have an obvious lifecycle to hook into.

I think there's still an underlying problem to address, which is that in
general we shouldn't release a connection with an open transaction that
hasn't been poisoned back into the pool. However, that's a slightly
larger change that can be addressed later.

Fixes #24004 (though this may require an upstream change for RSpec)
Fixes #23989
Fixes #24491
Close #24500
Close #24599

@sgrif

sgrif commented Apr 18, 2016

Copy link
Copy Markdown
Contributor Author

/cc @matthewd @rafaelfranca @arthurnn

@matthewd

Copy link
Copy Markdown
Member

See also cf075d9

@sgrif

sgrif commented Apr 18, 2016

Copy link
Copy Markdown
Contributor Author

I think the case of something like Capybara needs to be re-evaluated, as it knows it's going to be running in a context where autoloading would cause a deadlock. I would argue that it needs to call eager_load in that case, or we should assume we always want to eager load inside of integration tests.

This ensures that the "unit of computation" is an entire test, instead
of the request. This allows us to skip, for example, connection pooling.
This ensures that the same connection is used for the entire test.

We should arguably do this for all tests, but this level is the only
place that we have an obvious lifecycle to hook into.

I think there's still an underlying problem to address, which is that in
general we shouldn't release a connection with an open transaction that
hasn't been poisoned back into the pool. However, that's a slightly
larger change that can be addressed later.

Fixes rails#24004 (though this may require an upstream change for RSpec)
Fixes rails#23989
Close rails#24491
Close rails#24599
@sgrif sgrif force-pushed the sg-integration-testing branch from 9edc109 to fe1b500 Compare April 18, 2016 19:30
@sgrif

sgrif commented Apr 18, 2016

Copy link
Copy Markdown
Contributor Author

In either case, a regression test for cf075d9 should be added.

@jeremy

jeremy commented Apr 18, 2016

Copy link
Copy Markdown
Member

/cc @spastorino re. regression test

@sgrif

sgrif commented Apr 18, 2016

Copy link
Copy Markdown
Contributor Author

We also have several tests that are invalid, as they assume that integration tests are running through the executor. Worth updating them to test what they actually mean

sgrif added a commit to sgrif/rails that referenced this pull request Apr 18, 2016
When the query cache completes, if Active Record is still inside of a
transaction, it is because the transaction is meant to be left open
above this unit of work (such as transactional fixtures in tests). There
were several tests around the behavior of "tests" that were invalid, as
tests are not run through the executor. They have been changed to
reflect the new behavior, which is closer to what actually occurs in
Rails tests.

Fixes rails#23989
Fixes rails#24491
Close rails#24608
Close rails#24500
@sgrif

sgrif commented Apr 18, 2016

Copy link
Copy Markdown
Contributor Author

#24610 is likely a better approach for the long term

@spastorino

Copy link
Copy Markdown
Contributor

👍 will think about how to add a regression test.

@arthurnn

Copy link
Copy Markdown
Member

In order to test this, you need to change the test like https://github.com/rails/rails/pull/24500/files#diff-4836275ce5b6432a15ca07c1a15593d5L65 I think.

@jeremy

jeremy commented Apr 24, 2016

Copy link
Copy Markdown
Member

Is this blocking release candidate? Blocking beta4?

@sgrif

sgrif commented Apr 24, 2016

Copy link
Copy Markdown
Contributor Author

It would be nice to address but no, it is not blocking. The visible
symptoms of this have been addressed.

On Sun, Apr 24, 2016, 3:08 PM Jeremy Daer notifications@github.com wrote:

Is this blocking release candidate? Blocking beta4?


You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub
#24608 (comment)

@jeremy jeremy removed this from the 5.0.0 milestone Apr 24, 2016
@kamipo

kamipo commented Feb 3, 2018

Copy link
Copy Markdown
Member

Closing in favor of #24610.

@kamipo kamipo closed this Feb 3, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

7 participants