※ 引述《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 感谢您的指教 敝人不才 这边有另外一个问题想请教： 'object oriented and component-based software development' 是否为 'use case-driven software development'? 因为这个连结提到： "Anyone who works on object oriented and component-based software development projects needs to understand use cases and the role they play in use case-driven software projects." Link: http://www.parlezuml.com/tutorials/usecases.htm 在 Head First OOA&D 这本书中 (O'Really) 提到多种 Oo 发展方法 好比说：use case-driven, feature-driven, test-driven development 这麽多种方法，看起来没有规定 Oo 一定要用哪一种开发方式 但是它最後决定使用 feature-driven development 是吧？ 看起来 use case 好像是一切的源头，写完之後再做出需求功能的清单 最後再根据需求功能的清单进行分析和设计 所以我大胆断定，必须先有 use case, 这样才有办法进行 Oo 分析与设计 不知道这样的见解有没有错误呢？ 不管如何，unit testing 和 test-driven development 都和 OO 无关 这点应该是没问题.... -- 如有谬误就不用客气了.... --

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