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

Adds tests for invalid template variables #222

Merged
merged 1 commit into from
Jul 25, 2015
Merged

Conversation

codingjoe
Copy link
Contributor

Django catches all VariableDoesNotExist exceptions to replace
them in templates with a modifiable string that you can define in
your settings.
Sadly that doesn't allow you to find them in unit tests.

_fail_for_invalid_template_variable sets the setting
TEMPLATE_STRING_IF_INVALID to a custom class that not only fails
the current test but prints a pretty message including the template
name.

A new marker allows disabling this behavior, eg:

@pytest.mark.ignore_template_errors
def test_something():
    pass

This marker sets the setting to None, if you want it to be a string,
you can use the settings fixture to set it to your desired value.

@codingjoe codingjoe force-pushed the master branch 3 times, most recently from e7b1e95 to 8d90b0f Compare March 22, 2015 19:36
@codingjoe
Copy link
Contributor Author

I honestly don't know why the tests for 1.8 are failing. Does anyone have a clue to why the marker does not work?

@blueyed
Copy link
Contributor

blueyed commented Mar 23, 2015

This changed in 1.8: https://docs.djangoproject.com/en/1.8/ref/templates/upgrading/

It should only be deprecated, but maybe there's a bug with that, so that e.g. TEMPLATE_STRING_IF_INVALID does not get mapped properly.

@blueyed
Copy link
Contributor

blueyed commented Mar 23, 2015

The problem is likely that you would need to change the TEMPLATE setting for Django 1.8+, because you configure it after Django has applied its translation into the new setting.

@codingjoe
Copy link
Contributor Author

@blueyed thanks, I'll look into that and tie it up.

@codingjoe codingjoe force-pushed the master branch 5 times, most recently from 9ce0665 to e73eade Compare March 23, 2015 21:21
@codingjoe
Copy link
Contributor Author

@blueyed I fixed the django 18 issue and added documentation. Have fun!

"""Fixture that fails for invalid variables in templates.

This fixture will fail each test that uses django template rendering
should at template contain an invalid template variable.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

s/at/a/

@blueyed
Copy link
Contributor

blueyed commented Mar 23, 2015

Very nice, I've left a few comments.

@codingjoe
Copy link
Contributor Author

@blueyed thanks, I updated my commit.

@pelme
Copy link
Member

pelme commented Mar 29, 2015

This would be very useful!

I think this should be opt-in (maybe as a pytest.ini setting+marker for local overrides?). Just enabling it for everyone will probably break a lot of existing tests.

Maybe this (InvalidVarException) can be contributed back to Django somehow too, maybe it can be useful outside of pytest too.

@codingjoe
Copy link
Contributor Author

@pelme I don't really think that Django has any interest in that patch. They actually have an exception that they always catch.

Regarding opt-in/out: I think this is an exceptable change for a minor version. And yes, some people will have to fix some templates upgrading. But only if there templates are wrong ;)

If you want me to make this an opt-in feature, let me know, I'll update my code and doc.

@pelme
Copy link
Member

pelme commented Mar 30, 2015

This is similar to DEBUG_PROPAGATE_EXCEPTIONS = True that used to be set by pytest-django, but it broke peoples test suites: #26. Yes, Django has some bad defaults here, and everyone should be better of by fixing these problems, but just changing this and breaking existing test suites is not nice. :/

Therefore I think that this feature must be opt-in, but it is certainly something I'd like to use myself.

@codingjoe
Copy link
Contributor Author

@pelme sure, I'll update my PR

@codingjoe
Copy link
Contributor Author

@blueyed @pelme there you go. I added a command line option --test-templates to opt-in.

@blueyed
Copy link
Contributor

blueyed commented Mar 31, 2015

@codingjoe
Thanks! I'd like to see a (config file) option for this, too.

@pelme
Copy link
Member

pelme commented Mar 31, 2015

@codingjoe Very nice!

What about naming the option a bit less generic than --test-templates, maybe something like --fail-on-template-vars ?

@codingjoe
Copy link
Contributor Author

Sure, will do. Might actually be a good Idea as I'm thinking about writing more template tests like a py.test wrapper for tidy-html5.

@codingjoe
Copy link
Contributor Author

@blueyed all done.

# Configure FAIL_INVALID_TEMPLATE_VARS
itv = (options.itv or
early_config.getini(INVALID_TEMPLATE_VARS_ENV) or
os.environ.get(INVALID_TEMPLATE_VARS_ENV))
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should be changed to prefer the environment variable before the config, see #199.

@landscape-bot
Copy link

Code Health
Repository health decreased by 0.87% when pulling 194ac51 on codingjoe:master into 85bc9d5 on pytest-dev:master.

@codingjoe
Copy link
Contributor Author

@blueyed I swapped the config.

@landscape-bot
Copy link

Code Health
Repository health decreased by 2% when pulling cc7cc10 on codingjoe:master into 24a114f on pytest-dev:master.

@landscape-bot
Copy link

Code Health
Repository health decreased by 2% when pulling cab769a on codingjoe:master into b48c02d on pytest-dev:master.

@landscape-bot
Copy link

Code Health
Repository health decreased by 2% when pulling e21193a on codingjoe:master into b48c02d on pytest-dev:master.

@codingjoe
Copy link
Contributor Author

@blueyed oh yes, sorry, I fixed that.

@blueyed
Copy link
Contributor

blueyed commented Jun 1, 2015

@blueyed oh yes, sorry, I fixed that.

I think it might be good if it would use "1" for the environment variable, and allow "0" to disable it.
Currently it seems to be "set and non-empty" => True, otherwise False.
Seems to be confusing to use "True", if "False" would be also True.

Django catches all `VariableDoesNotExist` exceptions to replace
them in templates with a modifiable string that you can define in
your settings.
Sadly that doesn't allow you to find them in unit tests.

`_fail_for_invalid_template_variable` sets the setting
`TEMPLATE_STRING_IF_INVALID` to a custom class that not only fails
the current test but prints a pretty message including the template
name.

This behavior can be used with the new `--test-templates` command line option.
A new marker allows disabling this behavior, eg:

    @pytest.mark.ignore_template_errors
    def test_something():
        pass

This marker sets the setting to None, if you want it to be a string,
you can use the `settings` fixture to set it to your desired value.
@codingjoe
Copy link
Contributor Author

@blueyed I hope that does fixes the issue. Please feel free to fix any typos while merging. I'm dyslexic and going into a 20th-ish review cycle is somewhat disencouraging.

@landscape-bot
Copy link

Code Health
Repository health decreased by 0.53% when pulling 954081f on codingjoe:master into b48c02d on pytest-dev:master.

@codingjoe
Copy link
Contributor Author

@blueyed @pelme anything that is stopping this from being merged?

pelme added a commit that referenced this pull request Jul 25, 2015
Make it possible to fail tests for invalid template variables. Thanks to Johannes Hoppe for the patch and Daniel Hahler for review.
@pelme pelme merged commit adedb06 into pytest-dev:master Jul 25, 2015
@pelme
Copy link
Member

pelme commented Jul 25, 2015

@codingjoe Thanks a lot for fixing all the comments and sticking with it. This is a great feature that I will use myself. Sorry for the slow response, but now it is merged and will be included in the next version (which probably will be out during/after this weekend).

@blueyed
Copy link
Contributor

blueyed commented Jul 25, 2015

@codingjoe
I'm also sorry for forgetting about this.
And thanks indeed for sticking with me/us and providing this great feature! 🌷

@coveralls
Copy link

coveralls commented Nov 4, 2016

Coverage Status

Changes Unknown when pulling 954081f on codingjoe:master into * on pytest-dev:master*.

else:
msg = "Undefined template variable '%s'" % var
if self.fail:
pytest.fail(msg, pytrace=False)
Copy link
Contributor

@blueyed blueyed Mar 17, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@codingjoe
Do you remember why you used pytrace=False here?
I think it is very valuable to have a traceback in case of errors, isn't it?
(it might need to be massaged a bit to make it shorter though).
(via #470)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nope, I don't. I think back then there trace didn't give you much information, because the template engine worked differently. That was before you could switch engines, if I remember correctly.

Copy link
Contributor

@blueyed blueyed Mar 17, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@codingjoe
Thanks for your feedback, enabled it in 760fb18 (#470).

blueyed added a commit to blueyed/pytest-django that referenced this pull request Mar 17, 2017
blueyed added a commit to blueyed/pytest-django that referenced this pull request Apr 17, 2017
mfa pushed a commit to aexeagmbh/pytest-django that referenced this pull request May 17, 2017
dulacp pushed a commit to dulacp/pytest-django that referenced this pull request Dec 2, 2017
timb07 pushed a commit to timb07/pytest-django that referenced this pull request May 26, 2018
beyondgeeks added a commit to beyondgeeks/django-pytest that referenced this pull request Sep 6, 2022
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.

5 participants