※ 引述《H45 (!H45)》之铭言： : ※ 引述《PsMonkey (痞子军团团长)》之铭言： : : 简单地说，传统结构式的语言，像 C 的 function : : 你还是可以套用 Unit Test 的观念吧？ : : ^^^^ : : 又没说一定要... cccc : : ㄜ... 我书念得不多 : : 可以讲一下，如果 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 test 时通常会比较针对 interface 提供的东西来作测试, 但test case 本身是用来测试特定的 implementation 的. 换而言知, 对 test case 而言, 它是知道它 要测试的是哪一个 implementation, 产生实 体该由 test case 自己做就好, 如非必要, 不必另外藉由 factory 去 instantiate. 而 unit test 的理念该是尽量只碰你要测试的 class 就好, 如果还去找个 factory 来生产你 要的 impl 的话, 涉及与 test 不相关的东西就变多, test case 的准确程度反而变低. : 不知道这样的回答有没有解释到.... : 虽然我还是比较赞同 unit testing 和 OO 没有直接的关系 : 但是还是试图说明了一下 unit testing 要怎麽和 OO 扯上关系 Alien --

※ 发信站: 批踢踢实业坊(ptt.cc) ◆ From: 202.22.246.26 ※ 编辑: adrianshum 来自: 202.22.246.26 (07/20 14:16)