#35118: Mention test-suggestions when specific email-backend is used
-------------------------------------+-------------------------------------
Reporter: jecarr | Owner: nobody
Type: | Status: closed
Cleanup/optimization |
Component: Core (Mail) | Version: 5.0
Severity: Normal | Resolution: invalid
Keywords: | Triage Stage:
| Unreviewed
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 1
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Changes (by Natalia Bidart):
* status: new => closed
* resolution: => invalid
Comment:
Replying to [comment:5 jecarr]:
> I believed I was following the docs anyway: I didn't change the
`EMAIL_BACKEND` setting in my project. I just used an
[https://docs.djangoproject.com/en/5.0/topics/email/#smtp-backend SMTP
EmailBackend] instance as my `connection` parameter when creating an
`EmailMessage` or to call `connection.send_messages()`.
The usual pattern and recommended approach to change the email backend is
to change the `EMAIL_BACKEND` setting. In fact, the docs you linked say:
''The SMTP backend is the default configuration inherited by Django. If
you want to specify it explicitly, put the following in your settings:
`EMAIL_BACKEND = "django.core.mail.backends.smtp.EmailBackend"`''
> This then mirrors Baptiste Mispelon's code example on how my test cases
sent actual emails:
I do understand your use case now, thank you and thanks Baptiste for the
clarification. Still, building a backend instance and passing it
explicitly to `send_email`, while supported, is not the common case.
Passing a `connection` is usually done when a different/specific backend
is needed for a specific email message. And to be clear, I'm not saying
that your code is incorrect, I'm saying that the usual way of using the
`SMTP` backend (or any other backend across a project) is to override the
setting, for which the Django ` setup_test_environment` has support.
> > We may consider adding a note in the docs, but the clarification
should be quite explicit about *when* a backend override is needed in
tests, since the proposed PR could be read as that the tests always need
an override (when, in practice, they almost never need one).
>
> I thought I was explicit about when the override is needed? My PR begins
with "If your application defines a different email backend to be used
[other than locmem]".
Is not explicit in that the most common approach associated with "your
application defines a different email backend" is to override the
`EMAIL_BACKEND` setting. If we were to add a clarification to the docs
(I'm not convinced yet), it should clearly state that the test override is
needed only in those less common cases where a connection is passed
explicitly in the code.
Something along the lines:
{{{
.. admonition:: Testing email sending with custom connections
If your email sending code explicitly passes a `connection` object,
ensure
that tests appropriately handle the connection to prevent the actual
sending
of emails during test runs. In such cases, consider using mocking
techniques
to simulate the behavior of the connection without triggering actual
email
delivery.
}}}
> edit - I see what you mean, I meant if a connection parameter is used as
opposed to if a different email backend is used.
Yes, exactly!
> Replying to [comment:1 Baptiste Mispelon]:
> > I think we should try to find a systematic solution to the problem but
if that's too hard we should at least document quite loudly that one must
pay attention when using a custom `connection`.
>
> I therefore think this point still stands rather than this being about
multiple email backends (do point out if I'm misunderstanding how that
links!).
The thing is that, IMHO, when multiple email backends gets implemented,
the `connection` param will likely be deprecated in favor of an email
backend name, similar to how the database `using` parameter works. So,
considering both this goal and the fact that passing custom email
connection is not the common case, I really don't think is worth investing
time and resources into automagically mocking custom email connections.
--
Ticket URL: <https://code.djangoproject.com/ticket/35118#comment:6>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/0107018d17cd4589-267f4cce-dd0a-4830-b0b3-73fb7f466c05-000000%40eu-central-1.amazonses.com.
