Category Archives: Testing

Using Mockito with Spring

Junit testing is an integral part of unit testing while developing any application. It makes sense at times to separate out testing of Business layer from DAO layer to avoid generation of test data everytime or may be DAO layer is being developed independently.

Frameworks like Mockito or Easymock comes handy when dealing with such situations where you only want to test one class or one method and mock any other dependencies by dummy objects.

Here is a simple example


@RunWith(MockitoJUnitRunner.class)
public class UserManagerTest{
	private static final String userName="kamal";
	
	@InjectMocks
	private UserManager userManager=new UserManager();
	
	@Mock
	private UserDAO userDAO;
	

	@Before
	public void initMocks() {
		MockitoAnnotations.initMocks(this);
	}
	
	//Remove the Ignore tag to execute the test case
	@Ignore
	@Test
	public void addUserTest()
	{
		try {
		
			Mockito.doNothing().when(userDAO).insertUser(userName);
			Mockito.when(userDAO.getUserDependencies(userId)).thenReturn(new UserDependencies("temp"));
			
			userManager.addUser(userName);
		} catch (Exception e) {
			fail("Test case failed");
			// TODO Auto-generated catch block
			e.printStackTrace();
		}
	}
	

}

We are calling userManager.addUser(userName), but at the same time we are telling JUnit to do nothing (do not call the DAO layer), when you see this call to avoid data insertion. In addition there is another method which will check user dependencies (may be after adding user it check if there are some default depenedencies), where we tell Junit to instead of calling real DAO method and fecthing an objects, lets return a dummy object.

Stress Testing the application!

Yesterday I needed to quickly test one of web modules for performance. Easiest way was to do some stress testing, simulate real world environment (100 users hitting url at the same time) and then checking the service response time. It looked simple, I just needed a stress-testing tool, which could take url of my webpage and return me the performance data. But it turned out much more complex than that.

First shock came when I came to know that not many professionals are doing stress testing for their applications. I checked with some of my friends and got the same answer that they were not doing stress testing. How could I blame others when I did stress testing for one of my applications like 4 years ago.

Anyway, I knew that I would have to figure out things from scratch. I was told about Apache Benchmark (ab).  That looked promising to start with and I was able to get some performance data for static sites. But I was not able to look at the output, that ab was bringing back from the site. I tried to figure out how to check it for some time, but it turned out to be complex process, and I wanted to get over with the testing as soon as possible as other pending work was waiting.

So I though of using some UI based tool rather then command based (that’s the disadvantage of getting used to Windows). I googled around and found Jmeter, which looked very promising, and my kind of tool (open source). Again it started off well. And this time I was able to get back the output. The Jmeter could show the output in multiple formats, including HTML. This also helped to see that the output I was getting back from website was actually an error message instead of the correct page. The tool was showing the test case as success, because the error message was actually embedded in the correct HTML page (based on some conditions, it was to be shown or hidden). Now I figured out that this was because the tool was not able to set values in session for multiple test cases. Jmeter looked promising and I was sure that there must be some place where I could set the session settings (it had a lots of settings options for cache/ cookies etc). But too many setting options could only confuse. I again spent a couple of hours on this tool before giving up.

Time was running out, and I needed a tool that could help me testing my application without much complexity. So I thought of trying trial version (14 days or some limited features) of some paid software, when I figured out webserver stress tool’s. That worked like piece of cake. All the required settings were just 3-4 screens. Setting up sessions meant just checking the check-box for cookies. Clear output files with detailed logs, Summary log, and logs for each user simulated, url logs etc made it easier to compare different performance parameters. The paid version is also cheap (less than 250$) for this.

Anyone has better ideas for load/ stress/ performance testing of the application?

Selenium- A Web Application testing tool

Sometime back I analyzed selenium tool for testing the application from UI. Here are some notes which I created during the analysis

What is it: The Selenium is a web testing tool that promises to test any web application from UI. The tool has capabilities to record and play the test cases.

Downloadable: It provides two types of basic installations- IDE (for Firefox), RC- Remote Control (for all browsers).

How to use

Using Selenium with Firefox (FF): Using Selenium with FF is pure vanilla. The Selenium IDE can be simply installed with FF as a plug-in. This has capability to record and play the test cases. Go to any simple website (say google) with a small form (lets search for Kamalmeet)
Step1: Open the URL for webpage
Step2: Fill the form
Step3: Submit the form
Step4: Check for desired message (In this example with google, lets check if the desired website was listed. Selenium provides you various options; you can look for a text on the webpage to mark the test case as a success)

Once all the steps are done. Just stop the recording. A test case is ready. Now I can play this test case and all the above mentioned steps would execute automatically.

Using Record and Play technique, we can create much more complex test cases (say 10 forms or screens are involved). These test cases can saved and imported to any machine with FF. Additionally, the cases can be exported to languages like Java, Ruby, C#, Perl, PHP and Python.

Advantages:
1. The test cases can be created just by browsing through the application. Not even single line of coding required.
2. Test cases can be exported to multiple languages. For Java it means it gets imported as JUNIT test case. Now they can be run as standalone JUNIT test cases on any machine.
3. JUNIT test cases can be further modified by developers as per need.

Limitations:
1. The IDE is limited to Firefox
2. Did not get satisfactory results for dynamic contents. If text is changing dynamically at run time, the Selenium was not able to recognize. This might require more analysis.
3. Pop-ups: If the window has a pop up, say ok cancel button, the tool was not able to handle it smoothly. More analysis required here.

Using Selenium with Internet Explorer (IE): Using Selenium with IE is not as straight forward as it is with FF, still possible. We need to create test cases manually in this case and then execute.

One way to create test cases is as mentioned above, run the application in FF with Selenium IDE and export the test cases in Java.

Secondly we can actually create the test cases manually. This is as not very tough, but certainly more work than using tool with FF. We would need to understand the tool in more depth and figure out Java commands which it uses internally and then create appropriate test cases.