Testing Message2

[schwehr]

Taking a quick look at adding a test for Message2 and getting some suspicious results. Couple of surprising things that I see:

• Messages 1, 2, and 3 are the same except for the message id (or effectively they can be represented 100% the same with a tiny bit of larger code side on the message state)
• longitude and latitude in message and position are confusing at it seems that are confusing names as they are signed 1/10000 degree position and longs
• rot, cog, looks like the raw values not the turn rate
• Is there a reason not to break out the submessage?

This is also an example of junit4 with test discovery and a touch of cleanup. I did a by hand conversion of tabs to 4 spaces as tabs cause endless tool troubles for me. Would be maybe best to pick a formatter tool and setting and use that?

Thoughts?

package com.aisparser;

import static org.junit.Assert.assertEquals;
import static org.junit.Assert.fail;

import org.junit.Test;
import org.junit.runner.RunWith;
import org.junit.runners.JUnit4;

/** Tests for {@link Message2}. */
@RunWith(JUnit4.class)
public class Message2Test  {

    // Verifies decode of Msg 2 for a ship in a turn.
    @Test
    public void testParse() {
        Message2 msg = new Message2();

        try {
            Vdm vdm_message = new Vdm();
            int result = vdm_message.add("!AIVDM,1,1,,B,284;UGTdP4301>3L;B@Wk3TnU@A1,0*7C\r\n");
            assertEquals("vdm add failed", 0, result);
            msg.parse(vdm_message.sixbit());
        } catch (Exception e) {
            fail(e.getMessage());
        }

        // From libais:
        //     2, 0, 541255006, 4, -78, -271.591522217, false, 0.40000000596,
        //     0, 41.947201666666665, -62.606396666666669, 114, 27, 1, 1, false);

        assertEquals("msgid",  2, msg.msgid());
        assertEquals("repeat", 0, msg.repeat());
        assertEquals("userid", 541255006, msg.userid());
        assertEquals("nav_status", 4, msg.nav_status());
        assertEquals("rot", 178, msg.rot()); // TODO: Expected -78
        assertEquals("sog", 4, msg.sog());
        assertEquals("pos_acc", 0, msg.pos_acc());
        assertEquals("longitude", 25168321, msg.longitude()); // 41.947201666666665
        assertEquals("latitude", -37563838, msg.latitude()); // -62.606396666666669
        assertEquals("cog", 1996, msg.cog());
        assertEquals("true_heading", 114, msg.true_heading());
        assertEquals("utc_sec", 27, msg.utc_sec());
        assertEquals("regional", 4, msg.regional());
        assertEquals("spare", 1, msg.spare());
        assertEquals("raim", 0, msg.raim());
        assertEquals("sync_state", 2, msg.sync_state());
        assertEquals("slot_timeout", 4, msg.slot_timeout());
        assertEquals("sub_message", 1089, msg.sub_message());
    }
}

[bcl]

Taking a quick look at adding a test for Message2 and getting some suspicious results. Couple of surprising things that I see:

* Messages 1, 2, and 3 are the same except for the message id (or effectively they can be represented 100% the same with a tiny bit of larger code side on the message state)

True, but I like keeping them all as separate parse functions for consistency instead of cluttering up a common parser with extra logic.

* `longitude` and `latitude` in message and position are confusing at it seems that are confusing names as they are `signed 1/10000 degree position` and longs

They are the raw 1/10000 positions value with sign. In C there is a pos2ddd function that converts them to decimal lat/long but it looks like I never wrote the equivalent function for Java. It would probably go in the Position class.

* rot, cog,  looks like the raw values not the turn rate

Correct, for the most part aisparser just presents the raw values to the user and lets them decide how they want to deal with them.

* Is there a reason not to break out the submessage?

I don't remember anymore :)

But my current philosophy is to change as little as possible while cleaning things up and adding tests. There are quite a few people using this codebase so I'd like to get better tests in place first, do a new release (I tagged my old one from 2015 as v1.0.0 today), then we can start changing the API. This will give people a better update path if they want to take it.

This is also an example of junit4 with test discovery and a touch of cleanup. I did a by hand conversion of tabs to 4 spaces as tabs cause endless tool troubles for me. Would be maybe best to pick a formatter tool and setting and use that?

IIRC I wrote this using Eclipse. These days I use vim with 4 spaces everywhere (except for Go which insists on tabs), so if there is a java tool like go fmt that will reformat things in a nice consistent way feel free to include that.

[schwehr]

12aede5 of pr #21 adds a junit4 based message2 test so closing this. Thanks for commenting on my list of surprises.