java - 我应该测试枚举吗？

Question

如果您有一个仅包含值的简单 ENUM。 setter/getter 可用。

• 是否应该为此 ENUM 编写单元测试？
• 测试是否应该涵盖所有类型名称？

有什么建议吗？

// ENUM with constructor and methods.
public enum Planet {
    MERCURY(3.303e+23, 2.4397e6),
    VENUS(4.869e+24, 6.0518e6),
    EARTH(5.976e+24, 6.37814e6),
    MARS(6.421e+23, 3.3972e6),
    JUPITER(1.9e+27, 7.1492e7),
    SATURN(5.688e+26, 6.0268e7),
    URANUS(8.686e+25, 2.5559e7),
    NEPTUNE(1.024e+26, 2.4746e7);

    // Members
    private final double mass; // in kilograms
    private final double radius; // in meters

    // Constructor
    Planet(double mass, double radius) {
        this.mass = mass;
        this.radius = radius;
    }

    // Accessors
    public double getMass() {
        return mass;
    }

    public double getRadius() {
        return radius;
    }
}

Answer 1

这不是一个简单的是或否问题，而是在很大程度上取决于上下文。

如果这个枚举是一个大型项目的关键部分，有很多程序员和薄弱的沟通结构，并且你想确保没有人意外地改变了这个关键部分，一个合理的 junit 测试可能看起来像这样:

public class PlanetTest {
    private final static int NUM_PLANETS = 8;

    @Test
    public void testIntegrity() {
        assertEquals(NUM_PLANETS, Planet.values().length);

        for (Planet planet : Planet.values()) {
            assertTrue("Wierd: Mass in kg is less than radius in m", 
                planet.getMass() > planet.getRadius());
            }
        }
    }

编写此测试用例(在 IDE 的帮助下)比阅读您的问题花费的时间更少，并且您可以确信没有行星丢失或有损坏的值(每次回归测试运行一次)。

编写测试代码(在测试驱动开发中)的另一个好处是程序员被迫在他/她编写实际代码之前考虑实现问题。这可以改进代码的微设计。即使在这个微不足道的例子中，我也能想到在实现之前要考虑的问题:

• 是否应该有一种方法以英里或公里为单位返回半径？
• 是否应该有一种返回以吨为单位的质量的方法？
• 出于某些遗留原因，冥王星是否应该被视为行星？
• ....