-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
base: master
Are you sure you want to change the base?
Test message rendering #9460
Conversation
825c1a3
to
0ceb1e8
Compare
0ceb1e8
to
8f34373
Compare
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. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good!
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. |
* 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 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Use camel-case consistently.
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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; |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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'); |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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?
4c0b172
to
0a5f089
Compare
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.
0a5f089
to
63c90ef
Compare
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 theirMessage-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?