Skip to content
New issue

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

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

Already on GitHub? Sign in to your account

ckanext tests fail when ran together with ckan's #299

Closed
vitorbaptista opened this issue Jan 24, 2013 · 2 comments
Closed

ckanext tests fail when ran together with ckan's #299

vitorbaptista opened this issue Jan 24, 2013 · 2 comments
Assignees

Comments

@vitorbaptista
Copy link
Contributor

No description provided.

@ghost ghost assigned vitorbaptista Jan 24, 2013
vitorbaptista added a commit that referenced this issue Jan 24, 2013
We also, instead of always loading test.ini in these tests, we use whatever Pylons loaded.
vitorbaptista added a commit that referenced this issue Jan 24, 2013
… for

The problem I found was when you're testing a bunch of things
sequentially. Then, the first time that method is called, it
loads all known AuthFunctions and puts into a cache. Then it
only checks that cache.

But what happens if some code, after this has happened, adds
a new AuthFunction? It never gets added to the cache.

With this change, if we have the requested function on cache,
we use it. If not, we refresh the cache and see if something
changed.
vitorbaptista added a commit that referenced this issue Jan 24, 2013
This might not be the best way to do it. It's too repetitive, but it's
better than leaving trash behind.

We might investigate running the tests inside a transaction, and rolling
back when we're done (is it done already?).
vitorbaptista added a commit that referenced this issue Jan 24, 2013
The problem is that we were looking for each *_preview.js, when the included
files are already minified (*_preview.min.js).
@domoritz
Copy link
Contributor

Partially fixed in #290

domoritz pushed a commit to domoritz/ckan that referenced this issue Jan 28, 2013
This might not be the best way to do it. It's too repetitive, but it's
better than leaving trash behind.

We might investigate running the tests inside a transaction, and rolling
back when we're done (is it done already?).

Conflicts:
	ckanext/jsonpreview/tests/test_preview.py
	ckanext/pdfpreview/tests/test_preview.py
	ckanext/reclinepreview/tests/test_preview.py
vitorbaptista added a commit that referenced this issue Feb 5, 2013
We also, instead of always loading test.ini in these tests, we use whatever Pylons loaded.
vitorbaptista added a commit that referenced this issue Feb 5, 2013
… for

The problem I found was when you're testing a bunch of things
sequentially. Then, the first time that method is called, it
loads all known AuthFunctions and puts into a cache. Then it
only checks that cache.

But what happens if some code, after this has happened, adds
a new AuthFunction? It never gets added to the cache.

With this change, if we have the requested function on cache,
we use it. If not, we refresh the cache and see if something
changed.
vitorbaptista added a commit that referenced this issue Feb 5, 2013
This might not be the best way to do it. It's too repetitive, but it's
better than leaving trash behind.

We might investigate running the tests inside a transaction, and rolling
back when we're done (is it done already?).
vitorbaptista added a commit that referenced this issue Feb 5, 2013
The problem is that we were looking for each *_preview.js, when the included
files are already minified (*_preview.min.js).
vitorbaptista added a commit that referenced this issue Feb 5, 2013
This removes the following warning:

/home/vagrant/pyenv/local/lib/python2.7/site-packages/sqlalchemy/sql/expression.py:1925:
SAWarning: The IN-predicate on "term_translation.term" was invoked with an empty sequence.
This results in a contradiction, which nonetheless can be expensive to evaluate.
Consider alternative strategies for improved performance.
vitorbaptista added a commit that referenced this issue Feb 19, 2013
This is a hack.

We probably should configure all IConfigurable plugins whenever we load a new
one. We have to do this because they're configured before setup_class is ran,
so DataStore never gets configured.
vitorbaptista added a commit that referenced this issue Feb 21, 2013
@vitorbaptista
Copy link
Contributor Author

This was solved by #363

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

No branches or pull requests

2 participants