※ 引述《PsMonkey (痞子军团团长)》之铭言： : ※ 引述《H45 (!H45)》之铭言： : 简单地说，传统结构式的语言，像 C 的 function : 你还是可以套用 Unit Test 的观念吧？ : : 不得不承认真的不 OO 了 : : 虽然物件导向的分析和设计中 : : 如果采用 test-driven development 的话 : ^^^^ : 又没说一定要... cccc : : Unit testing 会是很重要的一环 : : 在分析的时候，不只是把 unit testing 纳入考虑，也一并加入了系统的架构 : : 整个系统的发展将会与 unit testing 习习相关。 : ㄜ... 我书念得不多 : 可以讲一下，如果 unit testing 纳入考量 : 会在 OOAD 的阶段产生什麽影响吗？ : 如果有考虑跟没考虑，OOAD 的过程跟结果会差很多 : 那或许在这里提 unit testing，有其必要 : （但是刚开版就来这个... 也许... [逃]） 因为 OOAD 的上一层是软体工程 所以系统在开发的过程中势必少不了一些前提 现在就假设以 test-driven 的方法来开发软体 开发程式之初，最需要的就是「需求的撷取」 再度假设现在已经知道了系统的需求与功能 那麽紧接着就是做一连串的 test case 做完了 test case 之後就是真的去发展系统本身 但是系统发展的过程中，不是每次都能够像 waterfall 一样从头就做到尾的 而是会有数次的 iteration, 进行循序式的发展 也许哪天系统需求有了变化，也许设计上有些元件不够具有弹性 或者某些类别的命名不太理想，又或许突然发现套用一个 design pattern 会更好 那麽这个时候当初订下来的 test case 是否也需要做一些调整呢？ 答案很明显是肯定的。 这个时候如果又刚好是 Object oriented language 那麽就会出现另一个问题：test case 要怎麽设计会比较具有弹性？ 一般而言，test case 必须对介面进行呼叫，而非针对叶类别进行呼叫 因为叶类别在系统发展中处於一个不稳定的状态，而介面却往往是最稳定的 所以 test case 就会倾向於呼叫介面的操作。 但是呼叫介面的操作之前又必须先产生实体才有办法真的做测试 要解决产生实体的问题又可以使用 factory pattern 来设计 整个就变得和 OOAD 十分的有关系了 不知道这样的回答有没有解释到.... 虽然我还是比较赞同 unit testing 和 OO 没有直接的关系 但是还是试图说明了一下 unit testing 要怎麽和 OO 扯上关系 -- 如有谬误，仍然请不吝指正 --

※ 发信站: 批踢踢实业坊(ptt.cc) ◆ From: 218.211.211.53 ※ 编辑: H45 来自: 218.211.211.53 (07/20 00:01)