by Mario La Menza

Sidebar: Get started with MockMe

feature
Oct 23, 20074 mins

JME development with XML-based mock objects

In this sidebar to “XML data interchange in Java ME applications,” author Mario La Menza introduces MockMe, a free tool for generating XML-based mock objects so you can test the presentation layer of your Java mobile applications without waiting for server-side data.

MockMe is a simple tool that allows you to test your Java mobile application’s client code without waiting for the service layer to become available. In complex applications this means not having to wait for data to become available for processing.

MockMe is essentially a configurable servlet based on properties files, which searches for XML files from a local directory according to a parameter passed in with a data access request. It then emulates the future server to facilitate testing. Once you have defined the XML and configured MockMe, both parts can work in parallel.

In the next sections I’ll quickly get you started with MockMe, first with setup instructions and then with tips for using it in your Java mobile application development.

Setting up MockMe

Because MockMe is a WAR you only need to place it in the deploy directory of your server (in Tomcat this would be /webapps). Figure 1 shows a Tomcat deploy directory after the MockMe.war has been deployed.

Figure 1. Deploy directory after the MockMe.war deploy

Within the MockMe directory, you will see the following:

Figure 2. MockMe structure

XML files that you want the server to return are stored in the XML directory. You will edit these files according to your needs and store them for the tool to return later, according to the operation code it receives.

Figure 3. XML files stored in the /XML directory
Figure 3. XML files stored in the /XML directory

Properties, config, and operations files

The properties, config, and operations files are essential for configuring MockMe. The association between operation code and XML files takes place in the operations file.

Figure 4. Association between operations and files

The general configuration parameters of the tool are found in config.properties.

Figure 5. Configuration parameters in config.properties

The operator parameter

The operator parameter specifies the name of the operation parameter that will be passed in the petition URL. A petition for this configuration would be of the form:

http://localhost:8080/MockMe/mock?codoper=31

If you want to use the oper operator instead of the codoper, go to config.properties and replace the first line with

operator = oper

Random parameter

The second parameter refers to the way you want the results to be returned if more than one XML file is used for one operation code (see Figure 4). If you have the following:

random = yes

it means that the server must select the XML files at random. In the case of code 31, there are two different files, which means that it could return either of them. If instead you have

Random = no

it would only return the first from left to right for a given operation. (xml31-1 in the case of Figure 4).

Log parameter

The third parameter refers to the possibility of the tool logging the petitions received. This log will be recorded in the log files (localhost.DATE.log) that are in the log directory.

You can cancel this option with log = no. But if there are problems with the configuration files, the errors will be informed anyway by means of this mechanism.

Finally, petitions to the tool can be made either from a browser or from the JME WTK emulator. Note that to petition from a mobile phone, the host where MockMe is placed must be published.

Whether using a browser or the JME WTK emulator, the petition for a given operation code will return the XML you have defined.

Figure 6. XML result of a login operation returned by MockMe

Figure 6 shows the result of a petition with operation code = 1 (which corresponds to the xml1-1 file).

Mario La Menza is a technical and managing architect and programmer. He is an expert JME developer and is a member of lm2a Mobility Solutions, Las Palmas, Spain. These days he is also finishing his PhD in computer science at University of Las Palmas de Gran Canaria. He regularly writes papers and articles about software development.