Over a million developers have joined DZone.

NetBeans Mobility Pack and Testing

· Java Zone

What every Java engineer should know about microservices: Reactive Microservices Architecture.  Brought to you in partnership with Lightbend.

I've recently converted to the use of the NetBeans Mobility Pack, even though I can't stand the large blob of control code that is auto-generated by the IDE. But this is not the topic for today: instead, I'd like to briefly talk about testing.

If you create a MIDP project or a MIDP library you'll find that there's no support for JUnit, but for a variant named JMUnit.

Quoting DevX, the reason is:

However, using JUnit or finding a JUnit extension for use in Java Micro Edition (ME) development has been a little tough. JUnit frameworks rely on Java reflection. Since the reflective API is not present in Java ME environments, typical JUnit tools, which rely heavily on reflection, do not help. In spite of this, there are two (soon to be one—more on this in a bit) Java ME JUnit extensions built especially for device application developers.

I'd like to counter contradict this assertion. Yes, it's true that JUnit requires reflection and there's no reflection on CLDC/MIDP - but who's saying that your tests must absolutely run in a J2ME environment? The test code is not production code after all, and why shouldn't I take advantage of the capability of the full J2SE (and the acquaintance with JUnit) for my tests? After all, J2ME is not full Java, but what it's really good in it is that it's a subset and can be mixed with full-fledged Java code.

What do you think? I believe that NetBeans should add the capability of using the regular JUnit for testing J2ME projects.

In the meantime, you can survive with a little trick:

  1. Let's say that you have a MIDP library project named MobileMaps (it's a component of windRose, a project of mine - you can check it out from https://windrose.dev.java.net/svn/windrose/trunk/src).
  2. Create a standard, J2SE library project named MobileMapsTest.
  3. Open the project properties and remove the "src" folder (not really needed, just to be picky).
  4. Go to the libraries panel and add MobileMaps in the dependencies of MobileMapsTest.
  5. Now, just create your tests with JUnit in MobileMapsTest. You can even use Java 5 if you want.

For instance, this is a small test for a MIDP class:

package it.tidalwave.microedition.map.osm;

import org.junit.After;
import org.junit.Before;
import org.junit.Test;
import static org.junit.Assert.*;

public class OSMTileSourceTest
private OSMTileSource fixture;

public void setupFixture()
fixture = new OSMTileSource();

public void tearDownFixture()
fixture = null;

public void testCachePrefix()
assertEquals("OSM/", fixture.getCachePrefix());

public void testDefaultZoomLevel()
assertEquals(9, fixture.getDefaultZoomLevel());

public void testDisplayName()
assertEquals("OpenStreetMap", fixture.getDisplayName());

public void testMaxZoomLevel()
assertEquals(17, fixture.getMaxZoomLevel());

public void testMinZoomLevel()
assertEquals(1, fixture.getMinZoomLevel());

public void testGetTileSize()
assertEquals(256, fixture.getTileSize());

public void testMetersPerPixel()
assertEquals(39135.758482, r(fixture.metersPerPixel(17 - 2)));
assertEquals(19567.879241, r(fixture.metersPerPixel(17 - 3)));
assertEquals( 9783.939621, r(fixture.metersPerPixel(17 - 4)));
assertEquals( 4891.969810, r(fixture.metersPerPixel(17 - 5)));
assertEquals( 2445.984905, r(fixture.metersPerPixel(17 - 6)));
assertEquals( 1222.992453, r(fixture.metersPerPixel(17 - 7)));
assertEquals( 611.496226, r(fixture.metersPerPixel(17 - 8)));
assertEquals( 305.748113, r(fixture.metersPerPixel(17 - 9)));
assertEquals( 152.874057, r(fixture.metersPerPixel(17 - 10)));
assertEquals( 76.437028, r(fixture.metersPerPixel(17 - 11)));
assertEquals( 38.218514, r(fixture.metersPerPixel(17 - 12)));
assertEquals( 19.109257, r(fixture.metersPerPixel(17 - 13)));
assertEquals( 9.554629, r(fixture.metersPerPixel(17 - 14)));
assertEquals( 4.777314, r(fixture.metersPerPixel(17 - 15)));
assertEquals( 2.388657, r(fixture.metersPerPixel(17 - 16)));
assertEquals( 1.194329, r(fixture.metersPerPixel(17 - 17)));
assertEquals( 0.597164, r(fixture.metersPerPixel(17 - 18)));

private static double r (final double v)
final int s = 1000000;
return Math.floor(v * s + 0.5) / s;

What you're losing is the wizard to create a JUnit skeleton test out of an existing class - you can survive without it, but it's a pity, that's why I think that JUnit should be supported by the Mobility Pack.

And at this point, the thing can even go under Hudson.

Microservices for Java, explained. Revitalize your legacy systems (and your career) with Reactive Microservices Architecture, a free O'Reilly book. Brought to you in partnership with Lightbend.


Opinions expressed by DZone contributors are their own.

The best of DZone straight to your inbox.

Please provide a valid email address.

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}