Update README.md: Minor updates

[ThomasLandauer]

Some questions/suggestions:

1. Could you show an example for guzzleRequestOptions and/or deleteEmailsAfterScenario?
2. I would merge "Added Methods" into "Example Test" (since it merely duplicates it). Is that OK?
3. Why is $I->fetchEmails(); necessary? Why isn't is possible to call $I->openNextUnreadEmail(); directly?

[koehnlein]

Hi Thomas, thanks for your input.

First of all I would like to explain, that this package is a fork of https://github.com/ericmartel/codeception-email-mailhog which was created for MailHog which is not maintained anymore.

My goal was to allow people to switch to Mailpit as easy as possible without any unnecessary changes.

Some questions/suggestions:

1. Could you show an example for `guzzleRequestOptions` and/or `deleteEmailsAfterScenario`?

To be honest, I never used these configurations by myself. But if you provide a pull request, I will check it will merge, if it is helpful.

2. I would merge "Added Methods" into "Example Test" (since it merely duplicates it). Is that OK?

I don't see a reason for that. The section "Added Methods" shows a short overview of the methods including a few words what te methods do, while "Example Test" is an example PHP code.

3. Why is `$I->fetchEmails();` necessary? Why isn't is possible to call `$I->openNextUnreadEmail();` directly?

This brings me back to the introduction I wrote at the top of the comment. This method always existed in the original package and my goal was to provide a 1:1 replacement as good as possible, so I never touched it. Of course it would be possible to refactor the functionality, but I do not see a reason to introduce such a major change.

[koehnlein]

It's not necessarily required to use Functional.suite.yml. You could also use the module in acceptance tests and it's even possible to configure the module in the global codeception.yml

[ThomasLandauer]

OK. But I think it's better to tell people the actual file name; this is also the way the Codeception docs are referring to those files.

[koehnlein]

I checked https://codeception.com/docs/modules/Db as example and cannot confirm, it's done this way in the Codeception docs.

[koehnlein]

It know that http://mailpit.dev is not a good example, because .dev is an existing TLD. But on the other hand, http://localhost is not really much better. I would prefer to have an example where everyone understands that it musst be changed to the real needs of the current setup, something like https://your-mailpit-instance or http://example.org

[ThomasLandauer]

http://localhost is the default URL that Mailpit runs on. So this isn't meant as some placeholder-domain, but rather the actual URL that works for new users.
Here's what I have in my Functional.suite.yml:

    config:
        Mailpit:
            url: 'http://localhost'
            port: '8025'

[koehnlein]

I don't see a need to change this line. Why would you do it?

[ThomasLandauer]

Just to explain what req stands for, cause some newbies might not understand it :-)

[koehnlein]

We can assume that users know how composer. The line is for simplification so that you can simply copy the command.

[ThomasLandauer]

I don't see a reason for that. The section "Added Methods" shows a short overview of the methods including a few words what te methods do, while "Example Test" is an example PHP code.

Yeah, but it makes README unnecessarily long IMO. The code (with your nice comments) says it all.

This brings me back to the introduction I wrote at the top of the comment. This method always existed in the original package and my goal was to provide a 1:1 replacement as good as possible, so I never touched it. Of course it would be possible to refactor the functionality, but I do not see a reason to introduce such a major change.

Well, since MailHog is dead, you're the boss now! :-)
The reason for me suggesting it is that it's error-prone (and verbose) to always have to call some "internal" function manually. The function could be emptied out and marked @deprecated - then it wouldn't even be a breaking change.

BTW: I just suggested it to be prominently listed at https://codeception.com/addons - see Codeception/codeception.github.com#880

[koehnlein]

I don't see a reason for that. The section "Added Methods" shows a short overview of the methods including a few words what te methods do, while "Example Test" is an example PHP code.

Yeah, but it makes README unnecessarily long IMO. The code (with your nice comments) says it all.

This brings me back to the introduction I wrote at the top of the comment. This method always existed in the original package and my goal was to provide a 1:1 replacement as good as possible, so I never touched it. Of course it would be possible to refactor the functionality, but I do not see a reason to introduce such a major change.

Well, since MailHog is dead, you're the boss now! :-) The reason for me suggesting it is that it's error-prone (and verbose) to always have to call some "internal" function manually. The function could be emptied out and marked @deprecated - then it wouldn't even be a breaking change.

I would prefer to discuss that in two separate issues and not use this pull request for that.

BTW: I just suggested it to be prominently listed at https://codeception.com/addons - see Codeception/codeception.github.com#880

Thanks.