您对产生复杂对象图的测试方法做了什么?

我是一个控件开发人员和一个相对新的单元测试人员。几乎每天,我都反对这种由于用户界面交互而无法测试控件的态度。我正在生成一个演示控件,以证明如果控件设计为可测试的,则可以显著减少手动测试。目前我有50%的逻辑覆盖率,但我认为如果我能找到一种方法来测试一些更复杂的部分,我可以将其提高到75%或更高。

例如,我有一个具有描述控件状态的属性的类和一个生成WPF的方法 PathGeometry 由若干段组成的对象。实现如下所示:

internal PathGeometry CreateOuterGeometry()
{
    double arcRadius = OuterCoordinates.Radius;
    double sweepAngle = OuterCoordinates.SweepAngle;
    ArcSegment outerArc = new ArcSegment(...);

    LineSegment arcEndToCenter = new LineSegment(...);

    PathFigure fig = new PathFigure();
    // configure figure and add segments...

    PathGeometry outerGeometry = new PathGeometry();
    outerGeometry.Figures.Add(fig);
    return outerGeometry;
}

我还有一些其他的方法,比如说,它们占据了几百块未覆盖的代码,额外的25%的覆盖率。我最初计划测试这些方法,但拒绝了这个概念。我仍然是一个单元测试新手,我能想到的测试代码的唯一方法是以下几种方法:

void CreateOuterGeometry_AngleIsSmall_ArcSegmentIsCorrect()
{
    ClassUnderTest classUnderTest = new ClassUnderTest();
    // configure the class under test...
    ArcSegment expectedArc = // generate expected Arc...

    PathGeometry geometry = classUnderTest.CreateOuterGeometry()
    ArcSegment arc = geometry.Figures.Segments[0];

    Assert.AreEqual(expectedArc, arc)
}

测试本身看起来很好;我将为每个预期的段编写一个。但我有一些问题:

• 是否需要测试来验证“第一段是 ArcSegment ?“理论上,测试测试这个,但是每个测试不应该只测试一件事吗?这听起来像两件事。
• 控件至少有六个用于计算的案例和四个边缘案例;这意味着对于每个方法,我至少需要十个测试。
• 在开发过程中,我多次更改了各种几何图形的生成方式。这将导致我不得不重写所有的测试。

第一个问题让我停顿了一下,因为它似乎会夸大测试的数量。我想我可能需要测试“有X段吗?”“n段是正确的类型吗?”,但是现在我已经考虑了更多,我发现方法中没有分支逻辑,所以我只需要做一次这些测试。第二个问题使我更加确信,与测试相关的工作将会非常多。这似乎是不可避免的。第三个问题使前两个问题复杂化。每次我改变几何体的计算方式时,我都要编辑估计的40个测试,以使它们尊重新的逻辑。这还包括在添加或删除段时添加或删除测试。

由于这三个问题,我选择编写一个应用程序和手动测试计划,将控件置于所有有趣的状态,并要求用户验证它看起来是一种特殊的方式。这是错的吗?我是否高估了编写单元测试所涉及的工作?是否有其他方法可以更容易地测试这一点?(我目前正在研究mock和stub;它似乎需要对设计进行一些重构,最终得到的效果差不多是如此。)