9 Replies Latest reply on Mar 15, 2014 3:40 PM by rbattenfeld

    Arquillian Mail Extension Proposal

    rbattenfeld

      Hi Aslak

       

      I am using in my company since quite a long time a mail test framework based on greenmail. Its an easy an powerful test mail framework. I developed already an resource adapter which hosts greenmail server. I see an good reason to provide an arquiliian mail extension.

       

      What do you think?

      Ralf

       

      PS: Happy new year to all of you.

        • 1. Re: Arquillian Mail Extension Proposal
          kpiwko

          Hey Ralf,

           

          I would say a huge +1 to any extension that brings power of another testing framework into Arquillian and putting it under Arquillian umbrella. Any extension can live its life separately, but the once hosted under Arquillian umbrella are indeed more visible. (Note to myself: we should have an extension "appstore"). If you would need some help with some administration (Maven Central, JIRA, etc.), I'd be happy to help you.

           

          Karel

          • 2. Re: Arquillian Mail Extension Proposal
            rbattenfeld

            Thanks a lot Karel, I need certainly help and guidance :-)

             

            I see this as a very slim extension without a huge implementation effort. It is basically just a framework which allows to verify that an outgoing mail is received by the mail server. This would be the starting point. At least, this is what I need here in my productive environment.

             

            Besides this, I am certainly want to make the descriptor reboot happening. This is still a top priority for me.

            I will try to contact you and Aslak in the chat room for further discussions.

             

            Tx, Ralf

            • 3. Re: Arquillian Mail Extension Proposal
              aslak

              Happy new years, Ralf!

               

              Simplification around Mail testing sounds very interesting.

               

              Do you have any notes on the current extension? What it does, how it works, what it could do in the future etc?

              • 4. Re: Arquillian Mail Extension Proposal
                rbattenfeld

                Happy new year too, Aslak!

                 

                With 'the current extension' you probably refer to something that already exists in the arquillian space, right? If yes, then I have to admit that I didn't know this mail test framework and have to check this.

                 

                I can briefly desribe how I implemented mail tests.

                1. For an isolated mail test, there is a test mail server required. I made good experience with the GreenMail test mail server.
                2. I developed a resource adapter that runs inside the mail server. You can predeploy this rar in your test environment or deploy it with your test archive.
                3. In the test case simply inject the mail session and the mail server's connection factory.
                4. With the mail session, do whatever you want to test.
                5. With the connection factory, you can verify your actions by quering or whatever action against the test mail server.

                 

                In fact, we test outoing smtp features only but the test mail server supports also imap or pop features too.

                 

                I created for speeding up a GIT repo. Here you find the test case that illustrates the steps above:

                https://github.com/jrbsoft/testmail-jca-adapter/blob/master/src/test/java/org/jrbsoft/jca/testmail/ConnectorTestCase.java

                Note that the implementation hides all the GreenMail functionality. It can be replaced with something else.

                 

                If there is a need, then I would love to host this under the arquillian space:-) I love in general things which can be used standalone or integrated in a test framework like arquillian.

                 

                Perhaps prehosting test artefacts like a test mail rar is a paradigm change for arquillian but in my experience, it makes things a lot easier. It is also thinkable to start the mail server on the client side and somehow the test case gets injected a reverence to the mail server.

                 

                Let me know what you think. If you see this as a benefit for arquillian, then I would love to push this:-)

                • 5. Re: Arquillian Mail Extension Proposal
                  aslak

                  > With 'the current extension' you probably refer to something that already exists in the arquillian space, right? If yes, then I have to admit that I didn't know this mail test framework and have to check this.

                   

                  No, sorry I missunderstood your first message. I thought you said you had created a Arquillian Mail Extension already that you had used internally..

                   

                  This looks very interesting. Mail always tend to be a bit tricky to test.

                   

                  > Perhaps prehosting test artefacts like a test mail rar is a paradigm change for arquillian but in my experience, it makes things a lot easier. It is also thinkable to start the mail server on the client side and somehow the test case gets injected a reverence to the mail server.

                   

                  Prehosting, or dynamically created during runtime.. same same but different. That's what Arquillian is all about.

                   

                  We have a fairly similar example in the CED book; https://github.com/arquillian/continuous-enterprise-development/blob/master/Chapter07-BusinessLogicServicesLayer.asciidoc

                   

                  I haven't studied it to close yet, but I see some IronJacamar stuff in example there. How tied is this currently to a specific JCA impl?.

                  • 6. Re: Arquillian Mail Extension Proposal
                    rbattenfeld

                    Sorry for the delay. I was two days abroad.

                     

                    The implementation is fully JCA 1.6 conform. IronJacamar produces the skeleton classes. I am sure this is very standard and doesn't need third party libs.

                    The example in the CED book is very similar I implement first. It works perfect ... unless you want do be EJB 3 spec conform. As an individual, running a server socket is ok but if it goes somehow public, then I would have problems with that.

                    That is the reason for the adapter.

                     

                    The main issue with this is that every app server bootstraps  rar's differently. It works nice with wildfly but needs more work with for example Glassfish. On the other hand, to configure the mail session along with the test mail server needs server side configurations as well. I am not sure that this is in every cases dynamically configurable in the different app server.

                     

                    My proposal is:

                    • Starting with the arquillian mail extension, it would be nice if you can point me to a good but simple example of an arquillian extension implementation
                    • First supported app server would be wildfly but the wildfly specific stuff is encapsulated so that later other apps can be easily supported. I am sure this is already design in many places by you and I can and should reuse this.
                    • Personally, I would go with the adapter approach, if possible.

                     

                    Tx, Ralf

                    • 8. Re: Arquillian Mail Extension Proposal
                      rbattenfeld

                      Thank you for the links, Aslak.

                       

                      I definitively would like to jump into this as soon SHRINKDESC-151 is finished. Then I have more time. I believe this extension is fairly simple one but still useful :-)

                       

                      Regards,

                      Ralf

                      • 9. Re: Arquillian Mail Extension Proposal
                        rbattenfeld

                        Hi

                         

                        Find here a first draft of an arquilian-extension-mail: https://github.com/rbattenfeld/arquillian-extension-mail-master

                         

                        Here are some details:

                        • As test mail server, I have used GreenMail. This one is not up to date but offers everything we need for test mails.
                        • GreenMail supports smtp, smtps, pop3, pop3s, imap, imaps
                        • The mail standard is 1.4
                        • My goal was to make it as simple as possible. It should easy and fast to implement.

                         

                        Let's go through the major parts:-)

                         

                        First thing is to configure the mail server. This is simply done with an class annotation:

                          @RunWith(Arquillian.class)

                          @MailServerSetup(protocols = {"smtp:3025", "imap:3026"}, users= {"john.doe@testmail.com:mypasswd"}, verbose = true)

                          public class MailTestWithUserVerificationTestCase { ... }

                         

                        As you can see, you can define multiple protocols with the corresponding port. And, you can also see how to add dedicated test mail users.

                         

                        Next, you to send a mail and how to verify it afterwards. I implemented to ways for verification. One is executed automatically and one allows you to test the mails directly. Lets look first the first option:

                            @Test

                            @MailTest(expectedMessageCount = 1, expectedSubject = "Wildfly Mail", expectedContentType = "text/plain; charset=us-ascii", clearAllMails = true, verbose = true)

                            public void firstTest() throws Exception {

                                final MimeMessage m = new MimeMessage(mailSession1);

                                final Address from = new InternetAddress("testUser1@noreply");

                                final Address[] to = new InternetAddress[] { new InternetAddress("john.doe@testmail.com") };

                         

                                m.setFrom(from);

                                m.setRecipients(Message.RecipientType.TO, to);

                                m.setSubject("Wildfly Mail");

                                m.setSentDate(new java.util.Date());

                                m.setContent("Mail sent from Wildfly ", "text/plain");

                                Transport.send(m);

                            }

                         

                        So, the MailTest annotation allows to define success criteria like expected mail count, expected subject line etc.. You can clear all mails for the test case is started, and you can turn on debug message.

                        This mode does check the success criteria automatically. Simple, I think.

                         

                        But what if you need the received mails for more detailed tests? Yes, this is also possible:

                            @MailRemoteClient

                            private MailTestUtil mailTestUtil;

                         

                        This annotation injects a test utility instance and allows, among other convenient operations, also to fetch the mails:

                          final List<Message> msgs = mailTestUtil.getReceivedMessages();

                         

                        And you can check what ever you want.

                         

                        The last piece is of course the mail resource as configured in the container:

                           @Resource(mappedName = "java:jboss/mail/Default")

                            private Session mailSession;   

                         

                        This configured by the user. The configuration has to match the test mail server configuration. Otherwise, the mail server doesn't receive mails.

                         

                        I didn't implemented everything right one but I think, the most important parts are here. Let me know what you think about my proposal.

                         

                        Thank you for your comments.

                        Ralf