TDD哲学用于激发使用组合的方法

时间:2011-07-26 12:17:12

标签: actionscript-3 tdd

我使用了测试驱动开发,然后进行了一些重新分解,最后得到了一组使用合成的类来逐步提高类型特异性。例如:

  • EventDispatcher - > TypedEventDispatcher - > FooEventDispatcher
  • EventDispatcher - > TypedEventDispatcher - > BarEventDispatcher

因此,EventDispatcher调度通用事件(String,Number,Object),TypedEventDispatcher仅根据对象调度事件,而FooEventDispatcher仅调度Foo事件,BarEventDispatcher调度Bar事件等。

所有类的测试具有相同的行为,唯一的区别是测试的对象类型。我发现当我想添加一个新的事件类型时,我最终会得到与其他类相同的测试代码。

这一重复数量显然是错误的。由此产生的测试非常脆弱,因为当我向TypedEventDispatcher添加新功能时,我需要向使用它的任何对象添加相同的测试。

在Java,.NET或Haxe中,我将创建一个泛型类型并对其进行测试,但是我使用的ActionScript不支持泛型,这就是为什么我需要为每种类型保持类型安全的新类

据我所知,我的选择是:

  1. 继续为每个新类创建相同的测试。
  2. 忽略派生类的测试,只需创建新类并假设它们有效。
  3. 选项#1看起来最“正确”,但也导致脆弱的测试。选项#2是有意义的,因为测试了基础对象(TypedEventDispatcher),因此派生类仍然可以工作。

    所以我的问题是,什么是TDD哲学,以激励创建基于作曲的新类?

    更新: 要以不同的方式提出问题,从现有代码派生功能时最终会出现重复的测试代码是否正常?

    更新

    BaseEventDispatcher测试:

    class BaseEventDispatcherTest {
        protected function test_dispatchEvent(dispatcher:Object, event:*):void {
            dispatcher.dispatch(event);
            assertEventDispatched(event)
        }
    }
    

    TypedEventDispatcher测试:

    class TypedEventDispatcherTest extends BaseEventDispatcherTest {
        [Test]
        public function dispatchEvent_TypedEvent_should_dispatch_event():void {
            var event:TypedEvent = new TypedEvent();
            test_dispatchEvent(dispatcher, event);
        }
    }
    

    FooEventDispatcher测试:

    class FooEventDispatcherTest extends BaseEventDispatcherTest {
        [Test]
        public function dispatchEvent_FooEvent_should_dispatch_event():void {
            var event:FooEvent = new FooEvent();
            test_dispatchEvent(dispatcher, event);
        }
    }
    

3 个答案:

答案 0 :(得分:2)

您知道可以从其他测试类继承测试类吗?

这可能适合您的情况。

答案 1 :(得分:1)

请问您对不同类型的调度员的动机是什么?当通常调度员不关心他们发送的内容时,将它们的功能分开似乎是多余的,只要它是一个事件。

如果您为不同的类创建相同的测试,那么它们可能会共享一些功能,这意味着您可以将所述功能放在层次结构中更高的位置并仅在您覆盖时进行测试。

答案 2 :(得分:1)

从您的评论中,听起来您正在尝试测试方法而不是行为,这可能导致测试中出现大量重复。

而不是像这样的一组测试:

  • 测试EventDispatcher的addEventListener
  • 测试EventDispatcher的removeEventListener
  • 测试EventDispatcher的displatchEvent
  • 测试TypedEventDispatcher的addEventListener
  • ...

我会有一组这样的测试:

  • 测试dispatchEvent是否通知已添加的侦听器
  • 测试dispatchEvent没有通知已删除的侦听器
  • 测试删除从未添加过的侦听器是否会被忽略

这些行为测试显然是EventDispatcher的功能,我觉得不需要为TypedEventDispatcher,FooEventDispatcher等复制它们。

但我想测试这些其他调度程序的独特功能,所以我可能会有这样的其他测试:

  • 测试FooEventDispatcher不通知Bar事件的侦听器
  • 测试TypedEventDispatcher不通知侦听器的String事件
  • ...

(如果你能在不提及课程名称的情况下描述这些测试,那就更好了,因为测试应该是推动设计或你的课程,而不是推动测试设计的课程。)

当然,我们的目标不是测试每种可能的组合,而只是测试实现我的软件所需的实际功能,并在需要之前保留其他功能。