-
Notifications
You must be signed in to change notification settings - Fork 562
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
Tests for template filters. #382
Conversation
1 similar comment
Thanks for this great improvement! Would you consider using Django's own builtin decorator for purposes of changing settings? It can avoid mock as a dependency.... but to be honest, I've been part of a project where mock ruined all the tests because it was used for everything :) https://docs.djangoproject.com/en/1.7/topics/testing/tools/#django.test.SimpleTestCase.settings |
Well, I'll try to rewrite. |
Now it's my turn to be honest - I used mock because could not achieve the same result by override decorator. For the tests I need to change the settings for the module wiki.core.permissions, but somehow built-in decorator does not work. But if in the same module to import settings directly from django.conf.settings, it has correct values. Unfortunately I do not know how to fix it. P.S. I also create question on SO. |
override_settings function just send a signal Forgive me in broken English ;-) |
Maybe you can do this: from wiki.conf import settings
class CanRead(BaseTestCase):
template = """
{% load wiki_tags %}
{{ article|can_read:user }}
"""
def test_user_have_permission(self):
settings.CAN_READ = lambda *args: True
a = Article.objects.create()
User = get_user_model()
u = User.objects.create(username='Nobody', password='pass')
output = can_read(a, u)
self.assertTrue(output)
output = self.render(self.template, {'article': a, 'user': u})
self.assertIn('True', output) |
@tkliuxing thanks for assistance, but your example seems like reinvent the wheel. It breaks tests isolation, which mean for each test should be written something like this
which can be pretty ugly and not convenient if need few settings. Meybe in some step you will invent context manager. Next step is decorating. P.S. Oh, believe me - my english even worse :D |
@Alkalit
This will trigger load-time events in the whole wiki application, I think this is what breaks the settings decorator because settings are then initialized before the test is run. Try moving all import statements interacting with |
And winner in nomination workaround of the year is... ta-daaah:
Tested it in few methods. Seems working. What do you think? |
And second place is awarded to:
|
1 similar comment
obliged! |
and thanks for finding a solution to settings overrides! |
No description provided.