Testing email sending functionality with a free mock smtp server

Intro

Often web applications include some email sending functionality that you have to develop/and test and there are certainly a lot of way to do this, use a fake-email recipient, use a dummy email recipient, spam your colleagues, etc. and there are some advantages and drawbacks to each of these approaches.

Recently I had to do some maintenance on an application that would send a massive amount of emails (mailing list) and I needed to test if everything was still working properly after the code modifications and since I had to change the application to allow sending multi-part messages with attachments there was a possibility that something was broken in the process.

Now for obvious reasons I could not test this in the production environment as it will have an impact on the company's SMTP server and the poor souls receiving an indecent amount of emails so I needed a mock or fake SMTP server to emulate this...

A solution

I present you Fake SMTP server. This great little Java program allows you to easily test your email sending functionality without side-effects (like spamming all your colleagues) by mimicking a real SMTP server.

Once the server is started and listening it will provide you with a list of received emails as well as SMTP logs and RAW email data and it works for both "simple" and MultiPart emails with attachments

How to use it ?

Just download it, unzip it and run it:

[/home/ufasoli/tools/smtp ~] java -jar fakeSMTP.jar

this will start the GUI but not the server for that you will need to click on the "Start server" button

There are also a few command line options that you can provide when starting the server like for example to start the server automatically :

• -o : Change the output directory
• -p : Change the listening port
• -s : Start the server automatically when you run the GUI

As indicated by the author on the websites there are a few alternatives :

• DevNullSmtp : Written in Java 1.4
• SMTP4dev : Written in .Net so not cross-platform

Requirements

The only thing you need to run this server is JVM 1.6+. Please also note that if you run this on a Unix/Linux environment you will need root privileges to listen on the port 25

Maven filtering test resources

When running tests in maven it's common usage to have configuration files that should be filtered.

When filtering "normal" resources the syntax is the following :

...

  
    
      
        ${project.basedir}/src/main/resources
        true
      

           
...

Whereas when filtering test resources the syntax is following :

 ...

  
      
          
              ${project.basedir}/src/test/resources
              true
          
      
  ...
  

Otherwise your test resources will not be filtered

Debugging a maven failsaife selenium build in intellij

Recently I had to debug a set of Selenium tests using the failsafe plugin and the embedded tomcat7 plugin using Intellij Idea

Usually you can just click on IDE's the debug button and Intellij will take care to launch the build and attach a debugger to the appropriate debug port:

However this time it wasn't working I had 2 issues with my build :

1. My breakpoints where completely ignored
2. The maven build just kept waiting without exiting the project even once the integration tests where finished

So I looked into the possible XML configuration tags for the failsafe plugin and thought that the <debugForkedProcess>true</debugForkedProcess> would be my salvation however I was wrong...

So what's happening here ?

By default, maven runs your tests in a separate ("forked") process. So when you set this property to true, the tests will automatically pause and await a remote debugger on port 5005

However this was not going happen since when you click on the IDE's debug button Intellij will execute a java debugging command similar to this :

java -agentlib:jdwp=transport=dt_socket,address=127.0.0.1:63093,suspend=y,server=n -Dmaven.home=C:\dev\bin\maven -Dclassworlds.conf=C:\dev\bin\maven\bin\m2.conf -Dfile.encoding=UTF-8 -classpath "C:\dev\bin\maven\boot\plexus-classworlds-2.4.2.jar;C:\dev\ide\intellij\lib\idea_rt.jar" org.codehaus.classworlds.Launcher --errors --fail-fast --strict-checksums clean verify -P selenium
Connected to the target VM, address: '127.0.0.1:63093', transport: 'socket'

Then the failsafe process will start and pause the tests waiting for a debbuger to attach to the 5005

-------------------------------------------------------
 T E S T S
-------------------------------------------------------
Listening for transport dt_socket at address: 5005

But as mentioned earlier this will not happen, because Intellij is listening on another port

Upon reading the plugin documentation over here I realized that you can change all of these configuration properties. However I kept reading the plugin documentation and found another promising configuration option <forkMode>true</forkMode>

According to the documentation the forkMode is an option to specify the forking mode. Can be "never", "once" or "always". "none" and "pertest" are also accepted for backwards compatibility. "always" forks for each test-class.

Since in our case we need to attach a debugger to a single thread in order to have our debugger to be called when hitting a break-point we will set this option to never

Now hit again the debug button in your IDE and normally Intellij should be summoned when your break-point is reached

Below is a sample maven configuration excerpt with the configuration for the failsafe plugin

...
  
    org.apache.maven.plugins
    maven-failsafe-plugin
    2.9
    
      
         integration-test
            
                integration-test
            
      
      
        verify
        
           verify
        
      
     
     
        never
     

...

as usual the full code for this application can be found over at my github account

the tests get executed when running the following maven goal :

mvn clean verify -Pselenium

a few tips for the road :

• Remember to use the suffix IT on your selenium test classes (e.g: MyTestIT.java) otherwise you will have to configure the surefire plugin to ignore them
• If like me you're running your selenium tests in a self contained mode (i.e : starting the application server, deploying the app, running the tests, stopping the server) remember to configure your server to fork to another process, otherwise the server running process will be started in a blocking mode