引述《adrianshum (Alien)》之铭言： : ※ 引述《H45 (!H45)》之铭言： : : 因为 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 OOAD只是开发流程中设计部分的一种方式.. 但开发流程等不等於软体工程, 应该是见人见智的问题.. 举凡 雏型式开发 瀑布式开发 到 渐进式及 ExtremeProgramming (英文不好, 前三个英文不会打, 请多包涵. XD) 哪一种是不包含 测试 这个部份的? 而且雏型 及 瀑布式开发等等 一些开发流程, 从尚未有OO的时代就已经发展出来了.. 所以话说回来. Unit Testing 严格说起来不只是针对 OO而已.. 应该说它是 测试 理论中的一部分. 均适用於 物件导向及结构式程式设计.. 所以那些发展出这套理论的人也都鼓励程式设计师遵循这些方法去测试.. 而非指特定的OOP, 目前比较常见的Junit 等等的测试工具. 是有人以特定的程式导向去实作出测试理论. 以便让某程式导向的Programmer 方便使用. 如此而已. 其实刚开始学的人, 很容易把某些工具跟理论或标准规格划上等号. 就像以前小弟小时候不懂事, 把FrontPage当作 Html一样. Unit Testing 归 Unit Testing, OOAD归OOAD 一个是测试. 一个是设计.. 要说有关系, 也不过是用 Unit Testing 去试你设计出来的东西对不对而已吧? --

※ 发信站: 批踢踢实业坊(ptt.cc) ◆ From: 218.160.124.20