Added grabEmail* functions

[TavoNiievez]

• Added grabSentEmails function.
• Added grabLastSentEmail function.

Both are available in the Yii2 module: here and here.

[ThomasLandauer]

I guess the same limitations apply as with https://codeception.com/docs/modules/Symfony#seeEmailIsSent, right? If yes, I'd suggest to move the limitations list to the top of the page, then link from all 3 email methods to it.

[ThomasLandauer]

Just noticing that these limitations are about to change :-) https://github.com/Codeception/module-symfony/blob/master/src/Codeception/Module/Symfony/MailerAssertionsTrait.php#L25

[TavoNiievez]

Hey @ThomasLandauer, very good observation.

All methods related to emails will still need $I->stopFollowingRedirects(); in v2.0, including grabSentEmails and grabLastSentEmail.

The exception is that if you are sending emails from a symfony command and you want to make assertions with emails (which will be possible in version 2) you don't need to use stopFollowingRedirects.

So one option is to move that explanation to the top of the page as you suggest (and update the examples too?).

[TavoNiievez]

@ThomasLandauer now that this is merged, can you please send a PR with the changes to the documentation?

[ThomasLandauer]

Yeah, but it will take a week or two :-(

[TavoNiievez]

don't worry I'll wait

[TavoNiievez]

the Symfony module can now directly call stopFollowingRedirects without the need for the REST module.

[ThomasLandauer]

Are the two weeks over already? ;-)

The only thing that's missing is the explanation about the restriction (i.e. stopFollowingRedirects), right?

Since this can be explained in one sentence, I no longer suggest to move this on top of the page, cause referring users to it ("see XY for whatever...) is almost as long as explaining it right there ;-)

So I'm suggesting to repeat this explanation identical for all three (?) email-related assertions:

• seeEmailIsSent
• grabSentEmails
• grabLastSentEmail

Some questions about the current wording:

The email is checked using Symfony message logger, which means:
If your app performs a redirect after sending the email, you need to suppress it using stopFollowingRedirects

1. Which "Symfony message logger"? The one at https://symfony.com/doc/current/logging.html#logging-a-message ?
2. At Added grabEmail* functions #107 (comment) you're saying that CLI is an exception. But I'm wondering if we really need to mention this, cause: There is no way to do a redirect in a CLI command (or is it?), so the current wording of the rule holds true for CLI as well: "If your app performs a redirect..."
3. Symfony offers three ways of redirecting, right?: return new RedirectResponse(), $this->redirect(), $this->redirectToRoute(). So mentioning all three explicitly is probably too much? But what about "If your app performs a HTTP redirect..." - this would make clearer what "redirect" we're talking about and also "exclude" the CLI case more.

and update the examples too?

Which examples?

BTW: Codeception/Codeception#6104 is getting more and more urgent - who's in charge of this rendering?

[TavoNiievez]

The only thing that's missing is the explanation about the restriction (i.e. stopFollowingRedirects), right?

Affirmative.

So I'm suggesting to repeat this explanation identical for all three (?) email-related assertions

I'm ok with this.

Which "Symfony message logger"? The one at symfony.com/doc/current/logging.html#logging-a-message ?

No... It refers to the class Symfony\Component\Mailer\EventListener\MessageLoggerListener, which unfortunately seems not to be documented on Symfony.com . I came across it by reviewing the symfony code regarding email assertions and discovered that such a service exists and can be used for testing.
In fact, now I am not sure if it is the best to mention that in the documentation, although there is a causal relationship in the sentence and the name of the service is self-describing I do not think it contributes too much for the common user (who is not going to read the code of that class itself).

But what about "If your app performs a HTTP redirect..." - this would make clearer what "redirect" we're talking about and also "exclude" the CLI case more.

Totally agree.

Which examples?

docblock code examples like this one.

BTW: Codeception/Codeception#6104 is getting more and more urgent - who's in charge of this rendering?

I'm not sure. I would think Arhell, who seems to be actively committing to the website repo. But the truth is I have no idea.