Posts tagged ‘UnitTest’

Java Spring MVC 3.2.0 UnitTests

I had a bit of a fight today, I wanted to UnitTest some Java Spring MVC code that I’m using for a demo application. But after a lot of Googling, StackOverflow and hitting different documentation of Spring 3.0, 3.1 and 3.2 I finally came to an acceptable solution. Mind you a minimal sample to test MVC controller without having to go crazy with decelerations, attributes, injections and so on and so forth, you catch my drift. There has been a lot of movement from those three versions I mentioned and finally the spring UnitTesting lib has now been folded into Spring itself, this is good news.
Btw, I found the answer in the Spring MVC showcase on GitHub, where else ?

So lets take a look at what you need, bare minimum just the way I like it.

Using Maven, you will need the ref in your POM file

<dependency>
            <groupId>org.springframework</groupId>
            <artifactId>spring-test</artifactId>
            <version>3.2.0.RELEASE</version>
            <scope>test</scope>
        </dependency>

The controller class I’m using comes pretty much directly from creating a new MVC Spring project from Eclipse.

package us.kristjansson.springTest;
//
import java.text.DateFormat;
import java.util.Date;
import java.util.Locale;
//
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import org.springframework.stereotype.Controller;
import org.springframework.ui.Model;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RequestMethod;

/**
 * Handles requests for the application home page.
 */

@Controller
public class CxHomeController
{
       
        private static final Logger logger = LoggerFactory.getLogger(CxHomeController.class);
       
        /**
         * Simply selects the home view to render by returning its name.
        */

        @RequestMapping(value = “/”, method = RequestMethod.GET)
        public String home(Locale locale, Model model)
        {
                logger.info(“Welcome home! The client locale is {}.”, locale);
                //
                Date date = new Date();
                DateFormat dateFormat = DateFormat.getDateTimeInstance(DateFormat.LONG, DateFormat.LONG, locale);
                String formattedDate = dateFormat.format(date);
                model.addAttribute(“serverTime”, formattedDate );
               
                return “home”;
        }
       
}

Then lets look at the Test itself.

//
package us.kristjansson.springTest;
//
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
//
import static org.springframework.test.web.servlet.request.MockMvcRequestBuilders.get;
import static org.springframework.test.web.servlet.result.MockMvcResultMatchers.content;
import static org.springframework.test.web.servlet.result.MockMvcResultMatchers.status;
import static org.springframework.test.web.servlet.setup.MockMvcBuilders.standaloneSetup;
import static org.springframework.test.web.servlet.result.MockMvcResultMatchers.view;
import org.springframework.test.web.servlet.MockMvc;
//
import org.junit.Before;
import org.junit.Test;

public class TxHomeController
{
         //
         private static final Logger logger = LoggerFactory.getLogger(TxSample.class);
         private MockMvc mockMvc;

         @Before
         public void setup() throws Exception
         {
                 logger.info( “Setup CxHomeController” );
                 this.mockMvc = standaloneSetup(new CxHomeController()).build();
         }

         @Test
         public void TestController() throws Exception
         {

                 //
                 logger.info( “testing CxHomeController” );
                
                 // The CxHomeController’s view is "home" without content
                 this.mockMvc.perform(
                           get(“/”))
                                 .andExpect(status().isOk())
                                 .andExpect(content().string(“”))
                                 .andExpect(view().name(“home”) 
                                 );

         }
       
}

UnitTesting a door

I was explaining to somebody from non development world some time back what unittesting is about. At the time the best thing I could come up with was something along the way. Well if your building a house and then you install a door. Now you have to make sure the door works. In case of the door we write Unittest that makes sure that the door nob turns and does actually open the door. We also make sure that the door latches when it’s shut, further we make sure that the door fully opens and closes without any trouble. We make sure the key fits and can lock and unlock the door. Since we are at it we might as well shake the door and make sure nothing is rattling, that all screws were tightened up properly. Further if the door gets replaced it has to be verified that it works as well and the same key can be used as before.

The good part is once you have written the unittest it will work for the replacement door as well. This is where you get the most bang for you buck. Unless you never rewrite your software, that’s another story then. So let’s say your interior designer came up with a new door, a sliding door. Now your tests fail of course and they should, the function of the door has changed and it’s time to update the unittest. The base will stay the same the same key might still fit, the door should shut properly, etc. One of the new functions might be that the door slides open when a person walks into the sensor that triggers the door etc.

So how does it look when you need to unittest objects in your new webserver project. It’s similar but it’s a little different the problem is when you are running on a webserver you are running in a container. The container is the webserver. So logically you can’t test the door as the door can only be accessed when inside the container ( installed in the house ). The problem with that is that you do not want to unittest against a live webserver. As you can not get down to the object level to address the door directly. Therefor the trick is to setup a unittest environment that can fake the container / house. Once you do that your door thinks that it’s installed in a house and you can verify that the door functions as expected.

There is only one thing left to say, Jawoll Mein Agile Führer

Saved by a mock

We had these unittest that were dependent on a server that the code interacts with over Tcp/ip they just didn’t work.  These tests would seldom run on the build machine and sometimes not at all.  It came to the point that I had disabled all tests that had anything to do with using the send / receive functionality.  The problem was that you had to make sure the simulation server was running first.  If it’s not running it had to be activated, if it hung it had to be shut down.  Then re-activated, sometimes when it hung the machine needed a reboot and so on.  Some of those things you had to learn with others you just had to reboot and hope things were ok.   After a reboot sometimes they were sometimes not.

I wrote a mock object to abstract the whole Tcp/ip layer and socket interaction.  The mock pretends to be the COM component and to do the Tcp/ip connection.  In reality it’s just a debug only class that will be invoked by the unittests.  The developer that wrote the initial version of the interaction with the COM component that does the Tcp/ip calls wrapped all the calls to the COM component.  The wrapper also keeps state of what the component is up to.  In other words if the program calls the wrapper to send a request the state is set to “Sent” etc.  The benefit of the wrapper is that when in test mode I can just activate the mock instead of the COM component.

The mock object is just a simple class pretending to do the Tcp/ip transport.  Instead after a send is called it will come back in a bit with an answer.  A little faster than the server would have in response to a request.  That’s fine as the client is already waiting asyncronously for the answer.  It was a simple coding and hook up, a good return on investment.  After the mock was in place and playing nice using one of the tests I activated all of the others.  We haven’t had a problem since, no reboots here and there when the tests don’t work because of send / receive problems.