Mailer DevService Extension (beta)

[Melloware]

Working with the Quarkus Devs on Zulip I have been able to create a Mailer Dev Service and Unit test framework so you can test REAL e-mails while in local development.

I would appreciate any testing and feedback!

See: https://github.com/quarkiverse/quarkus-mailpit

[Stephane Epardaud]

Hi,

This looks really interesting, but I'm not sure I see what it adds to the existing dev mode for the mailer extension, which already has mocking and allows us to test sent emails (because they're not really sent)?

Why should I use this instead of the stock "dev mode" experience?

I'm not trying to be negative, I want to understand why I should use this, and reading the docs didn't make me see the light.

--
You received this message because you are subscribed to the Google Groups "Quarkus Development mailing list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to quarkus-dev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/238064fc-dfb6-4419-b9b3-2d65f3b328f5n%40googlegroups.com.

--

Stéphane Épardaud

[Melloware]

Stephane,

That is an excellent question.  First, I would say if you are happy with Mock Mail then there is no need for this Extension.  At my clients on the other hand, we send lots of emails and here was my reasoning for this extension in no specific order:

1.  I want my development environment to match my production environment as closely as possible.

2.  With the argument for mocks...why have a DevService Postgres/MySQL database? It is because you want to test Hibernate/JPA/SQL is all working like production and mocking a database would defeat the purpose. Why is SMTP treated differently?

3. Do you write HTML formatted e-mails?  If yes, a Mock will allow you to check the HTML generated but not visually inspect what the email looks like in a browser.  It is why Selenium can check DOM semantics but you still need humans making sure your email "looks" like you want it to.

4. Do you use attachments in your emails like PDF files?  We do A LOT and want to verify the attachment is on the email and inspect the generated PDF in the attachment.

5. Has all the same unit/integration testing capabilities as mock and MORE.

I can probably come up with some more but that is why I built this extension.  I hope that helps??

[clement escoffier]

Hello,

One difference is that the dev service acts as an SMTP server, while the fake mailer we have right now does not do anything.

So, the dev service is closer to the "real life" experience. It makes the mailer users connect to the SMTP server, adding a bit of latency. I believe it also does a few validation on the recipients, attachments ids and so one. Things we do not implement in the fake mailer. 

Clement

To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/ddd3e099-d0ce-47ce-a22c-319df7844cd5n%40googlegroups.com.

[Sergey Beryozkin]

It would be closer to what the OIDC extension would like to offer, right now, users can work with the live Keycloak container, but Steph has also opened a great PR (sorry Steph for the delay with getting it finalized) where users can start a lightweight Dev service very fast which works well especially for non-Keycloak users

Sergey

To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/CAKW6fif%3DANExHbBwhxO19%3DR66MnAN59xBGr%2B-dYTDEHd90%2B92A%40mail.gmail.com.

[DevEnol Channel]

Hi all,

I just want to share regarding Quarkus email usage. Currently at my clients, we develop a dedicated microservice for sending email. Depending on the usage, other microservices can send email via this microservice with REST endpoint or Kafka. Perhaps this could be turn into a quarkus extension.

To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/CAMsYBfVXi0EZT_kqCuouKNUvvNmgL7mfW2uMg6%3D72FkRCy4dVg%40mail.gmail.com.

[Melloware]

To add to my earlier comments its also to support these two 12 factor app principles.

• 12 Factor App: Backing services Treat backing services as attached resources
• 12 Factor App: Dev/Prod Parity Keep development and production as similar as possible

[Stephane Epardaud]

On Tue, 17 Oct 2023 at 15:01, Melloware <mellow...@gmail.com> wrote:

1.  I want my development environment to match my production environment as closely as possible.

Sure, that lets you verify connection options, I guess.

 

2.  With the argument for mocks...why have a DevService Postgres/MySQL database? It is because you want to test Hibernate/JPA/SQL is all working like production and mocking a database would defeat the purpose. Why is SMTP treated differently?

JPA is special in the sense that it's very hard to mock: things get in many tables, tests want to run SQL queries, different db drivers produce widely different results, etc.

Emails, as far as I've seen so far, are very limited data structures with a few headers (to/from/subject) and 1-2 content types.

Using the existing dev mode mocking, we're essentially getting exactly what we're sending back and can inspect it. This is muuuuuch harder to do with JPA mocking, hence why a postgres/mysql dev service makes a ton of sense.

 

3. Do you write HTML formatted e-mails?  If yes, a Mock will allow you to check the HTML generated but not visually inspect what the email looks like in a browser.  It is why Selenium can check DOM semantics but you still need humans making sure your email "looks" like you want it to.

Are you refering to your DEV UI extension?  That looks very sweet indeed, and I'm surprised to verify that the existing mailer DEV UI doesn't support that, but it would be fairly simple to reuse what you wrote and make it pull from the existing dev mock instead of the dev service, no?

 

4. Do you use attachments in your emails like PDF files?  We do A LOT and want to verify the attachment is on the email and inspect the generated PDF in the attachment.

Do you mean via the new DEV UI you added? By a human? Because that doesn't need a dev service to achieve, as I state above.

 

5. Has all the same unit/integration testing capabilities as mock and MORE.

OK, here I'm starting to think I'm missing a bigger picture in what the dev service provides.

 

I can probably come up with some more but that is why I built this extension.  I hope that helps??

It does help, but I'm thinking I must be missing something, because outside of making sure we're testing the SMTP extension itself (but then again, we're only testing that it works with this particular SMTP dev service) and its flags, and a really great DEV UI (that could easily be ported and backed by the existing mocking), I'm not seeing exactly what this adds. Perhaps there's a great API provided by this dev service that's better than https://quarkus.io/guides/mailer-reference#testing for testing sent emails?

Again, I'm assuming I'm not understanding things right and there's some context I'm missing, and I'm mostly asking this so that we can improve the documentation to make it crystal clear why this extension is better than the current testing support we have. So, please forgive my skepticism, I just want to make sure I understand :) 

[Melloware]

I think you are not understanding.  This is a REAL Server running mocks only captures what your data is doing and not real mailboxes capturing real SMTP mail with real protocol. Go back my JPA + Postgres thing.  You wouldn't mock that so why are you mocking mail?  This DevService does EXACTLY what the PostGres DevService does for a database this does for STMP email server.