I was given a Java project that processes Mails, both with and without SMTP Envelopes, and was told to update its dependencies as they were really old (roughly 10-15 years)
Now I am facing an issue - The program receives emails via james and SMTP, which can be inside an Envelope (but doesnt necessarily have to), of which we read out the information, in this case recipients.
I noticed that some of the Unit-Tests do not mock an SMTP Envelope, and just pass a mail file to test with, where despite there being no Envelope and consequently no "RCPT TO", it still returns values, which are the Message Recipients.
I dont want these. Is there any way to strictly say that I only want the values of the envelope "RCPT TO", or in other cases "MAIL FROM"? Or perhaps to check if the Message is contained in an Envelope?
This is pretty important, as we have faulty data sets from this in some cases, such as our parser responsible for taking Envelope and no CC Recipients - due to always getting the Message Recipient Headers this ends up creating a dataset WITH the CC Recipients anyway.
This is the responsible line of code:
Collection<MailAddress> addresses = mail.getRecipients();
The big question is: What does your code process at runtime? If it processes mails without envelope, the unit test is useful.
If it also gets mail with envelope, your unit test might be incomplete.
If it only gets mail with envelope, your unit test might be irrelevant.
We can't tell from the little detail that you provide, so the answer is a rather generic one: Make sure your unit tests are testing what needs to be tested. It's perfectly ok to test more, but if you only expect to process mails with envelope, it'd be absolutely fine to simply reject those without one (and test for rejection, rather than decoding).
Unfortunately (from a development & data decoding standpoint), the SMTP world is extremely heterogeneous, so I'd expect your best bet to be if you start sampling the real-world data. If all your SMTP data comes from a single internal system, you'll see less variation (and your unit tests might be useful). If they come in from outside, all bets are off.