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

Possible fix for view_config() referencing old registry #234

Closed
wants to merge 1 commit into from
Closed

Possible fix for view_config() referencing old registry #234

wants to merge 1 commit into from

Conversation

vhallac
Copy link

@vhallac vhallac commented Jul 13, 2011

view_config decorators are called only once for an entire test suite execution.
After tearDown() is called once, further calls to config.scan() fail to update
the registry of the associated renderer of a view, which causes test cases to
fail.

This patch contains a test case to highlight the problem, and a proposed fix.

I have first observed the problem when trying to register some classes during integration testing, and using them for views registered via the view_config() decorator. The first test would pass, and the rest of the tests would fail.

I tracked the problem down to Renderer not picking up my registered renderers after testing.tearDown() is called. Eventually, view_config() turned out to be the cause.

I could have made a more targeted fix that would check config.registry and renderer.registry, and reallocate if they are different, but I chose to re-allocate a renderer every time config.scan() is called.

view_config decorators are called only once for an entire test suite execution.
After tearDown() is called once, further calls to config.scan() fail to update
the registry of the associated renderer of a view, which causes test cases to
fail.

This patch contains a test case to highlight the problem, and a proposed fix.
@mcdonc mcdonc closed this in 2ad827b Jul 13, 2011
@mcdonc
Copy link
Member

mcdonc commented Jul 13, 2011

Thanks; I fixed it slightly differently but it should have the same effect. The fix will be present in 1.1b3 (or if there is no 1.1b3, then 1.1 final).

@vhallac
Copy link
Author

vhallac commented Jul 14, 2011

Thanks, that is a better way of detecting if the object has what we need.

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

Successfully merging this pull request may close these issues.

2 participants