Hi Andrei, On Fri, 2017-06-09 at 15:12 +0000, Andrei Dulvac wrote: > 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
Right > > 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. Yes, with a little note. The drive to write this code was that I want to execute tests both with container and without them. I could easily go with an infrastructure-driven solution and add a container which contains the mock server. But that would make the solution docker- specific. > > 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? What you have to do is install this bundle if you want email tests. Indeed, it's not 'free' if you already have junit.core included. But the downside would be the lack of cohesiveness in the junit.core bundle, as this email functionality is completely unrelated to the current purpose of junit.core . In my personal opinion the disadvantage of deploying an additional bundle is outweighed by the potential scope creep in junit.core . Robert > > - 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 > >
