Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

NetBeans Mobility Pack and Testing

DZone's Guide to

NetBeans Mobility Pack and Testing

· Java Zone
Free Resource

Download Microservices for Java Developers: A hands-on introduction to frameworks and containers. Brought to you in partnership with Red Hat.

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;

@Before
public void setupFixture()
{
fixture = new OSMTileSource();
}

@After
public void tearDownFixture()
{
fixture = null;
}

@Test
public void testCachePrefix()
{
assertEquals("OSM/", fixture.getCachePrefix());
}

@Test
public void testDefaultZoomLevel()
{
assertEquals(9, fixture.getDefaultZoomLevel());
}

@Test
public void testDisplayName()
{
assertEquals("OpenStreetMap", fixture.getDisplayName());
}

@Test
public void testMaxZoomLevel()
{
assertEquals(17, fixture.getMaxZoomLevel());
}

@Test
public void testMinZoomLevel()
{
assertEquals(1, fixture.getMinZoomLevel());
}

@Test
public void testGetTileSize()
{
assertEquals(256, fixture.getTileSize());
}

@Test
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.

Download Building Reactive Microservices in Java: Asynchronous and Event-Based Application Design. Brought to you in partnership with Red Hat

Topics:

Opinions expressed by DZone contributors are their own.

THE DZONE NEWSLETTER

Dev Resources & Solutions Straight to Your Inbox

Thanks for subscribing!

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

X

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

{{ parent.tldr }}

{{ parent.urlSource.name }}