我是TDD方法的新手,所以我想知道是否有人有经验,这可以启发我一点点.我想得到一些如何一起使用UML和TDD方法的线索.
我已经习惯了:用UML设计 - >生成骨架类(然后保持同步) - >实现,最后测试.我必须承认测试部分是最差的,所以我开始寻找其他东西--TDD.所以我有一些一般的知识是什么,但在我继续前进之前,我很感兴趣知道它如何与软件设计,特别是UML结合在一起.
所以当我第一次设计/创建测试时,UML如何适应？是否有可能首先设计类,从它们创建骨架类,从它们生成单元测试,这些测试将在UML预生成类的实际实现之前"填充",这会破坏整个TDD吗？或者还有其他方法可以将UML和TDD保持在一起吗？
mar*_*uns 12
TDD周期是测试,代码,重构,(重复)然后发货.正如TDD名称所暗示的那样,开发过程是由测试驱动的,特别是这意味着在开发或编写代码之前首先编写测试.
第一段是纯粹的定义......来自Kent Beck如何定义TDD ......或者维基人员如何理解TDD ...我认为有必要用这个定义来说明这一点,因为我不确定每个人是否都在讨论相同的TDD或者如果其他人真正理解TDD [最重要的部分或]定义的含义,那么首先编写测试的含义.换句话说,我认为更多关于这个问题的答案的焦点应该深入研究TDD,而不是解释对UML的偏见.我的回答的冗长部分与我对使用UML支持TDD的看法有关... UML只是一种建模语言,当然不需要做TDD; 如果应用得不恰当,它可能会妨碍...但是UML可以帮助理解编写测试的要求,如果需要建模可以帮助重构,以及如何收集过程的工件加速了所提供代码的文档.我欢迎任何评论,批评或建议,但请不要因为你同意或不同意第一段而上下投票我的答案...... TDD的首字母缩略词是测试驱动开发,这意味着测试优先发展.
第一次写测试意味着开发人员理解的规范和要求FIRST ......很明显,任何测试编写应该失败,直到代码被写入,但在TDD中,测试必须写第一个 -你不能这样做没有TDD在编写代码之前,在编写测试之前专注于理解需求规范.有些情况下根本不存在要求; 要求启发涉及到一些预先预先的alpha版本,以"将泥浆扔到墙上以查看粘贴"......这种事情不应该与开发相混淆,当然不是测试驱动的开发,它基本上只是一种形式的需求 - 对于一个知之甚少的应用领域的启发.
UML图是TDD的一种需求输入形式.如果知道创建UML图表的人员可用,那么这不是唯一的,但可能比书面规范更好.在实施前需求建模会话期间,通过可视化图表来更好地与探索问题域[与用户/客户/其他系统提供商]进行沟通...其中模拟性能是真正理解需求所必需的(例如CANbus网络交互) ); 如果我们可以使用Rhapsody或Simulink RT Workshop等可执行,模块化和完整的规范语言或CASE工具,它通常是理想的... UML不一定是TDD的一部分,但它是方法设计综合的一部分,在编写任何代码之前,需要花费更多的精力来理解所需的内容[然后浪费时间尝试将代码推销给关心的人 ]; 通常,更多地关注理解系统需求为更高效,更高效的敏捷TDD迭代奠定了基础.
重构是关于改进设计 - 清理工作,测试代码以使其更简单,更易于维护.您希望尽可能地收紧它以消除混淆的缠结,在这些缠结可能隐藏或可能在将来的版本中产生错误 - 您不会因为客户需要而重构; 你重构,因为运送干净的代码而不是继续支付支持/维护复杂的混乱的成本更便宜.通常,大多数TDD更注重代码; 但是,您可以使用UML查看更大的范围或退一步看问题,例如创建一个类图来帮助识别[缺失]测试或可能的重构.这不是您需要在一般情况下要求或想要做的事情,而是在适当的时候.
最后一步,'船'是一个重要的步骤......'船'不是"将它扔到墙上并忘记它的简写,因为好的代码不需要支持"或"放弃并希望没有更多迭代".从财务或业务角度来看,运输是TDD最重要的一步,因为它是您获得报酬的地方.运输涉及"换档",因为它包括系统集成,支持和维护准备,为下一轮开发做好准备等.UML图的主要用途是[以抽象方式]通信代码如何进行它的作用...... UML很有用,因为希望图表是需求和开发过程的工件; 当代码出货时没有必要从头开始......作为一种通信工具,UML适用于减少多模块系统的集成错误,可能涉及用不同语言编写的模块的大型项目,不同公司的嵌入式系统网络必须在安全关键系统上进行合作,但需要将抽象与他们的"专有知识"吝啬或保护.
就像你应该避免在一个小螺丝刀适当的情况下使用大锤子一样,或者你不会要求所有开发人员标准化使用Emacs作为他们的编辑器.有时候这个观点不值得攀登 - 你不想总是把UML旗帜拖出来或者知道那个一直在推UML的家伙......特别是在那些无法替代写作测试或阅读的情况下码.如果你坚持适当的情况,你不应该害怕在语言帮助你的所有情况下使用UML作为沟通语言.
虽然有些人认为UML是一种设计方法,但它首先是一种沟通工具.因此,统一建模语言的名称.这个想法是有一个共同的词汇(形状),你可以插入一本书,每个人都会理解.
另一方面,TDD是一种设计方法,从其接口和消费者开始构建系统的方式,然后才添加实现.
一旦您的设计因应用TDD而出现,您就可以使用UML来传达该设计.如果您不需要进行通信(就像您是唯一的开发人员一样),您可以说不需要UML.
有些人认为领域分析(识别关键名词,动词和形容词以及构建基本本体论模型)是UML方法的一部分,反映在用例和ER图中......这在你跳入之前可能有用. TDD红/绿/重构循环.再说一次,严格来说这是DDD(域驱动设计),而不是UML本身.
所以当我第一次设计/创建测试时,UML如何适应？是否有可能首先设计类,从它们创建骨架类,从它们生成单元测试,这些测试将在UML预生成类的实际实现之前"填充",这会破坏整个TDD吗？或者还有其他方法可以将UML和TDD保持在一起吗？
如果你创建一个完整的骨架类 - 我假设你的意思是一个所有方法定义但是空的类 - 在编写你的第一个测试之前,那么我会说你没有做TDD,并且失去了TDD的好处.当我们进行TDD - 测试驱动设计时 - 我们的测试逐步引导我们进入我们的程序所需的下一个元素 - 方法和类.如果您已经预先指定了UML,那么您的类和方法是什么,您的设计已经完成了很多,并且您的后续开发仅限于遵循它,或者您已经浪费了后续工作将要撤消的工作.
可能有一些方法可以同时使用UML和TDD进行设计,但正如您所描述的那样,在TDD获得机会之前,您正在使用UML进行设计.这不会给你TDD的全部好处.
如果您正在使用UML设计类,那么您正在设计您认为代码的外观.但是你使用TDD 创造的是现实.
将UML保留到最后,以记录使用TDD创建的代码的结果.
或者还有其他方法可以将UML和TDD保持在一起吗？
UML和TDD完美契合:
不要试图在步骤1或在重复步骤1(改进设计)之后做出许多设计决策.您希望在几周后的第一次迭代中完成步骤13.