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

Field inference strategies for django.contrib modules #3417

Closed
ajcerejeira opened this issue Jul 21, 2022 · 5 comments
Closed

Field inference strategies for django.contrib modules #3417

ajcerejeira opened this issue Jul 21, 2022 · 5 comments
Labels
enhancement it's not broken, but we want it to be better

Comments

@ajcerejeira
Copy link
Contributor

I noticed that _global_field_lookup does not define strategies for some form fields, s.a UsernameField and ReadOnlyPasswordHashField.

This makes the code below raise a ResolutionFailed exception:

from django.contrib.auth.forms import UserCreationForm
from hypothesis import given
from hypothesis.extra.django import from_form

@given(form=from_form(UserCreationForm))
def test_signup_form(form):
    pass
hypothesis.errors.ResolutionFailed: Could not infer a strategy for <django.contrib.auth.forms.UsernameField object at >

It is quite useful in Django to use, or inherit from UserCreationForm when creating signup forms, and providing a default strategies for these fields would make testing easier without requiring to register_field_strategy for those fields.


I also noticed that there are no strategies for form fields defined django.contrib.gis module, so I assume that would be out of scope for this integration?

@Zac-HD Zac-HD added the enhancement it's not broken, but we want it to be better label Jul 21, 2022
@Zac-HD
Copy link
Member

Zac-HD commented Jul 21, 2022

I would be delighted to add support for anything that ships as part of the django package, whether in django.contrib.auth.forms or django.contrib.gis (though the latter might be more difficult). Our main difficulty is simply that none of the current Hypothesis maintainers use Django, and so we're fairly cautious about guessing what would be useful or idiomatic.

If you're interested, I'd love to collaborate on a PR to add support for these fields 😃

@ajcerejeira
Copy link
Contributor Author

Thanks for the feedback @Zac-HD I created #3419 to address the django.contrib.auth.forms part. I assume the django.contrib.gis support would be trickier.


A slightly unrelated question, the django UserCreationForm defines two fields, password1 and password2 that must be equal. How can we express this requirement with the from_form inside given decorator? Something along the lines of:

@given(from_form(UserCreationForm, password2="same as password1"))
def test_user_creation_form():
    pass

@Zac-HD
Copy link
Member

Zac-HD commented Jul 22, 2022

I assume the django.contrib.gis support would be trickier.

Inasmuch as polygons are more complicated than strings, yep; but that's going from easy to medium rather than actually hard. Follow-up PR?

The django UserCreationForm defines two fields, password1 and password2 that must be equal. How can we express this requirement with the from_form inside given decorator?

The st.shared() strategy seems like what you want here - the trick is to ensure (and test) that we have a different key for each form.

From there, it looks like we need some automatic way for from_form() to recognize that two form fields must have the same value. Looking at the source, there doesn't seem to be any deliberate metadata for that, but we could add a pretty reliable heuristic based on the names and label of the fields.

@Zac-HD
Copy link
Member

Zac-HD commented Jul 25, 2022

I was just going through some notes and thought that pytest-dev/pytest-django#912 might also be of interest to you as Django dev 🙂

@Zac-HD
Copy link
Member

Zac-HD commented Aug 20, 2022

Closing this because we've solved the motivating use-case and I can't think of a good general heuristic for recognizing fields that need the same value.

@Zac-HD Zac-HD closed this as completed Aug 20, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement it's not broken, but we want it to be better
Projects
None yet
Development

No branches or pull requests

2 participants