Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Test message rendering #9460

Open
wants to merge 11 commits into
base: master
Choose a base branch
from
Open

Conversation

pabzm
Copy link
Member

@pabzm pabzm commented May 21, 2024

This adds an integration testing setup to check the rendering of individual emails. The idea is to grow this with a lot of "normal" and "interesting" messages, to have a solid base for fixing new rendering errors without breaking previous fixes (motivated by #9443). It would also help with possible refactoring.

Run ./tests/MessageRendering/run-tests.sh to run all tests in that directory. They are ignored when running the main test suite (for now).

The messages are served by a dovecot container from the Maildir in
tests/MessageRendering/src/maildir and identified by their Message-Id. This way one can drop a raw email into there, and immediately write a test against it.

This is not yet built into the GitHub workflows, and also has only a few messages and tests, because before putting more work into this I'd like to have some feedback.

@roundcube/webmail-developers What do you think about this?

@pabzm pabzm force-pushed the test-message-rendering branch 4 times, most recently from 825c1a3 to 0ceb1e8 Compare May 21, 2024 17:12
@pabzm pabzm marked this pull request as draft May 21, 2024 17:13
@pabzm
Copy link
Member Author

pabzm commented May 21, 2024

Sorry, it took me a moment to wrestle with phpstan, the cs-fixer and windows filename problems. It's ready now and I won't force-push anymore.

@pabzm pabzm marked this pull request as ready for review May 21, 2024 17:45
Copy link
Contributor

@miaulalala miaulalala left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good!

@pabzm
Copy link
Member Author

pabzm commented May 24, 2024

Actually this conflicts with the work I did for #9465 (which only occured to me yesterday), so I'd not push this before that other topic was discussed.

@pabzm pabzm self-assigned this May 29, 2024
program/actions/mail/show.php Outdated Show resolved Hide resolved
* to be placed as individual files in
* `tests/src/emails/test@example/Mail/cur/`.
*/
protected function run_and_get_html_output_domxpath(string $msg_id): \DOMXPath
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Use camel-case consistently.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry for mixing styles. https://github.com/roundcube/roundcubemail/wiki/Dev-Guidelines#classes-functions-and-variables says: "No CamelCase", but the repo has some. Which way would you prefer?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Camel-case here as this is a new class in tests.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok. Do you want CameCase only in new tests or in all new code?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No necessarily in tests, but in utility classes like this for sure. I think we can do this in tests too, especially in new files where there's no old code in another style.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, so we continue snake_case if the file already contains some, but if not we default to CamelCase?

Only in tests, or also in other code?

(Sorry for insisting, I want to understand thoroughly.)

$rcmail = \rcmail::get_instance();
// We need to overwrite the storage object, else storage_init() just
// returns the cached one (which might be a StorageMock instance).
$mock_storage = $rcmail->storage = null;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, we should probably not initialize ActionTestCase in tests bootstrap, but do it differently so it does not leak to other tests.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Until we improve that, can we use this code as it is? As far as I can see it doesn't break other tests.

$mock_storage = $rcmail->storage = null;
$rcmail->storage_init();
// Login our test user so we can fetch messages from the imap server.
$rcmail->login('test', 'pass', 'tls://localhost');
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In Browser tests we're using a standalone imap server from Greenmail. Maybe that would be better approach than dovecot. However, I don't know whether Greenmail's mail parsing and imap commands provide good quality results.

The Browser tests can also use any imap server, we need only username/password in config. That means you'd have to append the test messages if not in INBOX.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

n Browser tests we're using a standalone imap server from Greenmail. Maybe that would be better approach than dovecot

I'll have a look at it, thank you for the hint!

That means you'd have to append the test messages if not in INBOX.

I'm not sure I understand: If using Greenmail I'd have to append the messages? Or if using other folders?

Currently the code is only using the INBOX, because it focusses on the message's content rendering, not how listings are rendered. So then I don't need to append any messages, right?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

With dovecot you just start it with the maildir directory. With other servers you can't do this, especially with remote ones. See tests/Browser/bootstrap.php for some useful code that already exists.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you for the explanation!

Why do you think using Greenmail would be better? It is also "just" a standalone IMAP-Server, isn't it? Since we're not using Java, we cannot hook into it for our tests, as far as I understand.
With two standalone IMAP-Servers, wouldn't it be better to test against the one that is most used in live systems?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A developer should be able to easily run these tests on their PC. I think that using a self-contained file is better than a need to install dovecot in the system. Java will be required indeed, but I bet most people have it already.

On the other hand people might want to run tests with their own remote IMAP server.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This setup uses docker to run dovecot, you don't have to install it locally. Don't you think docker is an acceptable dependency for a test suite?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@alecpl Could you let me know if you think docker (or a similar container setup) is an acceptable dependency?

I don't really like to sudo-execute a binary downloaded from the internet, and would much prefer a container. We could still use greenmail, if you prefer that: https://hub.docker.com/r/greenmail/standalone

@@ -0,0 +1,44 @@
<?php
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would probably put these tests in tests/Actions/Mail/EmailRendering because it's testing the actions. Of course they would have to be skipped if imap server is not running or not configured.

But I understand you wanted to separate it on start.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd like to postpone the integration until it works as we want it, ok?

pabzm and others added 11 commits June 14, 2024 13:14
We can't test this code if it exits.
Run ./tests/MessageRendering/run-tests.sh to run all tests in that
directory, which are supposed to check the rendering of concrete
messages.

The messages are served by a dovecot container from the Maildir in
`tests/MessageRendering/src/maildir` and identified by their `Message-Id`.
The files will be renamed back by dovecot, but then they won't hurt our
unit test suite anymore.
We'll have to come up with a good way to avoid git reporting a lot of
filename changes, though.
To use another image, e.g. to test a different server implementation, or
because the default image doesn't run on your platform, create a file
called 'tests/MessageRendering/.env' and assign the variable
ROUNDCUBE_TEST_IMAP_SERVER_IMAGE in it.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants