我应该测试枚举吗?

时间:2017-12-15 07:31:28

标签: java testing enums

如果您只有一个简单的ENUM值。吸气剂可用。

  • 是否应为此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;
    }
}

1 个答案:

答案 0 :(得分:4)

这不是一个简单的“是或否”问题,而是在很大程度上取决于背景。

如果这个枚举是一个具有大量程序员和弱通信结构的大型项目的关键部分,并且你想确保没有人意外地改变了这个关键部分,那么合理的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的帮助下)花费的时间比阅读问题的时间更少,并确保没有行星丢失或损坏了值(一次和每次回归测试运行)。

编写测试代码(在测试驱动开发中)的另一个好处是程序员在编写实际代码之前 这可以改善代码的微观设计。即使在这个微不足道的例子中,我也可以在实施之前考虑要考虑的问题:

  • 是否应该有以英里或公里为单位返回半径的方法?
  • 是否应该有以吨为单位返回质量的方法?
  • 冥王星应该被认为是一个星球吗?
  • ....