Add KeyNamesTest to test key code to name mapping

[ziyaom2-stack]

Add KeyNamesTest to test key code to name mapping

[gemini-code-assist]

Code Review

This pull request introduces a new unit test class, KeyNamesTest, to verify the mapping of key codes to human-readable names. The feedback suggests adopting JUnit 5 best practices by using package-private visibility for the test class. Additionally, it is recommended to refactor the large test method into smaller, focused methods for better isolation and to expand coverage to include missing modifier keys and boundary cases, specifically highlighting a potential ArrayIndexOutOfBoundsException in the KeyNames implementation.

[gemini-code-assist]

In JUnit 5, test classes and methods do not need to be public. It is a best practice to use package-private visibility for better encapsulation and to adhere to modern Java testing idioms.

Suggested change

	public class KeyNamesTest {
	class KeyNamesTest {

References

1. Issues found in test code should be reported with a reduced priority, at most medium.

[gemini-code-assist]

The test method testKeyNamesMapping is quite large and covers many different categories of keys. Splitting it into smaller, focused test methods improves readability and failure isolation. Additionally, the current test is missing several modifier keys (Right Ctrl, Alt, Meta/Option) and boundary checks.

Note: The KeyNames class Javadoc claims support for keyId up to 255, but the implementation uses an array of size 0xFF (255), which causes getName(255) to throw an ArrayIndexOutOfBoundsException. This should be addressed in the KeyNames class, and a boundary test should be added here once fixed.

    @Test
    void testLetterAndDigitKeys() {
        assertEquals("A", KeyNames.getName(KeyInput.KEY_A));
        assertEquals("Z", KeyNames.getName(KeyInput.KEY_Z));

        assertEquals("0", KeyNames.getName(KeyInput.KEY_0));
        assertEquals("9", KeyNames.getName(KeyInput.KEY_9));
    }

    @Test
    void testSpecialAndArrowKeys() {
        assertEquals("Space",     KeyNames.getName(KeyInput.KEY_SPACE));
        assertEquals("Enter",     KeyNames.getName(KeyInput.KEY_RETURN));
        assertEquals("Backspace", KeyNames.getName(KeyInput.KEY_BACK));
        assertEquals("Esc",       KeyNames.getName(KeyInput.KEY_ESCAPE));

        assertEquals("Up",    KeyNames.getName(KeyInput.KEY_UP));
        assertEquals("Down",  KeyNames.getName(KeyInput.KEY_DOWN));
        assertEquals("Left",  KeyNames.getName(KeyInput.KEY_LEFT));
        assertEquals("Right", KeyNames.getName(KeyInput.KEY_RIGHT));
    }

    @Test
    void testModifierKeys() {
        assertEquals("Left Shift",  KeyNames.getName(KeyInput.KEY_LSHIFT));
        assertEquals("Right Shift", KeyNames.getName(KeyInput.KEY_RSHIFT));
        assertEquals("Left Ctrl",   KeyNames.getName(KeyInput.KEY_LCONTROL));
        assertEquals("Right Ctrl",  KeyNames.getName(KeyInput.KEY_RCONTROL));
        assertEquals("Left Alt",    KeyNames.getName(KeyInput.KEY_LMENU));
        assertEquals("Right Alt",   KeyNames.getName(KeyInput.KEY_RMENU));
        assertEquals("Left Option", KeyNames.getName(KeyInput.KEY_LMETA));
        assertEquals("Right Option",KeyNames.getName(KeyInput.KEY_RMETA));
    }

    @Test
    void testUnmappedKeys() {
        assertEquals("Unknown", KeyNames.getName(KeyInput.KEY_UNKNOWN));
        assertNull(KeyNames.getName(0x5C));
    }

References

1. Issues found in test code should be reported with a reduced priority, at most medium.

[riccardobl]

Thanks for taking the time to look into jMonkeyEngine.

In this case, I don't think we need a unit test. Since KeyNames is essentially a static mapping table, testing it would mostly mean duplicating the same mapping in the test code, which adds maintenance cost without giving us much additional confidence in correctness.