Hi Robert, Generally I think that's nice. I do have a concern I want to point out. See nr. 2 below.
The way I see it, we have two scenarios: 1. A testing job/ automation setup starts the Sling instances it needs to test and any other necessary things like a mock e-mail server. a. If the mock server is started inside the test, you don't need to concern yourself with the infra, to provision containers and whatnot. You can just run a test against an already-provisioned topology of instances. b. if the mock server is started as part of the provisioning itself, you always have to do it in order to run those tests What I understand from you is that if started in a container, the container can't access the outside host, where the tests are probably running (they could also be running on the other side of the globe, if they're http tests). What we've done for a long time in some Adobe AEM internal tests is use an "externalize" URI where the Sling-based instance can find the e-mail server, via an OSGi config. It becomes the responsibility of the container infra to allow for that to happen (mapping ports, for example). I understand this is your problem. 2. You do it as in your proposal and configure the OSGi service to hit itself via http. It's neat, but my concern is that you always have to do it - always install this test service if you want to be able to run the tests. We have this annoyance with some other test support bundles like the junit.core and junit.remote. Just wanted to point this out. If we're going to do it like that, at least let's bundle it up in junit.core? - Andrei On Fri, Jun 9, 2017 at 4:39 PM Robert Munteanu <romb...@apache.org> wrote: > Hi, > > I'd like to ask for input regarding the following testing solution I'm > working on > > https://issues.apache.org/jira/browse/SLING-6949 > > When working with email-enabled applications it is sometimes desirable > to interact with the emails send by the applications, either by > verifying the contents of the emails or just validating that a certain > email is sent. > > A good solution for this is Wiser, which works quite well. > > One scenario where this does not apply is when the application under > test is running as a container, and it cannot access the host > application to deliver emails to the Wiser instance. > > To have an unitary approach I propose that we create an OSGi bundle > which wraps Wiser and starts in the Sling application. The messages > received by Wiser can then be read using an HTTP API. > > I've committed an initial working prototype at > > https://github.com/apache/sling/tree/trunk/testing/email > > I am considering adding functionality to clear the email messages and > also adding client-side support in the org.apache.sling.testing.clients > bundle ( not yet decided for the latter ). > > Your thoughts are more than welcome on the subject. > > Thanks, > > Robert >
