Giters

testcontainers / testcontainers-dotnet

A library to support tests with throwaway instances of Docker containers for all compatible .NET Standard versions.

Home Page:https://dotnet.testcontainers.org

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

[Feature]: Module for MailHog container for integration testing SMTP clients

Spelchure opened this issue · comments

commented

Problem

Most of web applications need somewhat sending emails. MailHog is good choice SMTP for integration testing for sending emails. ( It also has API for checking whether email is sent or not) But it has drawback that it does not support SMTP over TLS under the hood.(Users of MailHog use proxy (e.g. stunnel) for eliminating this issue AFAIK)

Solution

We can create module for MailHog and encapsulate SSL logic inside this module. Users may decide whether they are want to use SSL or not through configuration. I’m planning to contribute this module what do you think about it?

Benefit

Users easily use this module for integration testing for SMTP mail sending

Alternatives

Users can use other docker images rather than MailHog or they may want to configure MailHog container themselves without using module

Would you like to help contributing this enhancement?

Yes

commented

Hi 👋 did you try the existing Papercut (1, 2) module? I think both are very similar, although I do not know if they share/support the same features.

commented

Sorry my bad I didn't see Papercut module but it does not support SSL also if I am correct but I think adding extra SMTP server module while Papercut exists seems redundant. Thank you for your response

commented

A few days ago, I came across stalwartlabs/mail-server or Mailpit, another mail servers that supports various features, which could be alternatives. I think we can offer multiple modules for the same/similar services, as we do with databases. However, I would prefer to consolidate and prioritize support for established providers rather than incorporating all kinds of providers. For simpler modules, developers can always fall back to the generic builder API (MailHog seems quite established, though).

commented

@HofmeisterAn whether or not the repo of the SMTP server is active is important for the priorization process? It seems there is no active development for the mailhog repo (source).

commented

@HofmeisterAn whether or not the repo of the SMTP server is active is important for the priorization process? It seems there is no active development for the mailhog repo (source).

I think that is a good point. I am happy to continue with Mailpit (finalize and merge the PR). I simply wanted to share the PR for transparency, ensuring that developers are not working on similar modules, and making sure we choose an implementation that covers most use cases.

commented

No worries, thanks for the review!