Announcement Announcement Module
Collapse
No announcement yet.
Testing javamail code Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Testing javamail code

    Folks,

    I was wondering how other people go about writing unit tests for code which uses the JavaMail API and Spring's JavaMail support classes. I'm having difficulty with this, mainly because the likes of MimeMessage and MimeMessageHelper don't lend themselves to making client code easy to test.

    For example, say I have a class which implements MimeMessagePreparator, and I want to unit test it. This class wraps the MimeMessage in a MimeMessageHelper. In order to test it, I need to inject a MimeMessage (which is a class) into the prepare() method.

    One approach is to let the code do its thing, and then try and write assertions on the structure and content of the MimeMessage. The problem with this is that MimeMessageHelper does some pretty tricky things behind the scenes with multiparts, and the resulting MimeMessage object is very complex. The test would end up being too simple to be of any real use, or nothing more than a case of "make the test fit what happens"

    Alternatively, I could use JMock to create a mock subclass of MimeMessage, and add expectations to the mock. But I neither know (nor care) what MimeMessageHelper is doing to the MimeMessage under the covers, and so again I wouldn't know what expectations to assert.

    It feels like Spring needs a more comprehensive abstraction around JavaMail, one that is interface based, but still retains the full power of JavaMail. The SimpleMailMessage abstraction is too simple for serious use.

  • #2
    Hi skaffman

    I am not trying to set the cat amongst the pigeons, but how about not writing unit tests for your mail-based classes?

    From the text in your post, you sound like you have already weighed the benefits of such unit tests against the value that such tests would provide, and come to the conclusion of 'it's not worth it'.

    Originally posted by skaffman View Post
    The test would end up being too simple to be of any real use, or nothing more than a case of "make the test fit what happens".

    Alternatively, I could use JMock to create a mock subclass of MimeMessage, and add expectations to the mock. But I neither know (nor care) what MimeMessageHelper is doing to the MimeMessage under the covers, and so again I wouldn't know what expectations to assert.
    Indeed. Unit test that portion of your code that passes the data structure to the code tasked with sending the email. You can then write integration tests to verify that the various components tasked with sending email are working correctly.

    Cheers
    Rick

    Comment


    • #3
      Unit test that portion of your code that passes the data structure to the code tasked with sending the email.
      The problem is with the javamail abstractions, it's hard to make that separation. The data structure in question is MimeMessage. The code that I want to test constructs a MimeMessage (via a MimeMessagePreparator and a MimeMessageHelper), it doesn't send anything (it just delegates to a JavaMailSender).

      The only way to unit test code, in general, is to either check its outputs (which means examing the produced MimeMessage), or checking it's interactions with its collaborators (which means mocking out MimeMessage). Neither is easy, or even practical.

      If I wanted to completely separate my code from javamail, then I'd have to write my own object model to represent email messages, have my code construct that model, test that, and then have more code that translates that into MimeMessage. Even assuming no need to test the latter (which is questionable), it still means an extra model layer that I don't want.

      Comment

      Working...
      X