NetBeans Mobility Pack and 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:
- 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).
- Create a standard, J2SE library project named MobileMapsTest.
- Open the project properties and remove the "src" folder (not really needed, just to be picky).
- Go to the libraries panel and add MobileMaps in the dependencies of MobileMapsTest.
- 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.
- Login or register to post comments
- 307 reads
- Flag as offensive
- Email this Story
- Printer-friendly version
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)






