{技术}{TDD}{嵌入式开发}
Robin
很多操作都是和资源相关的，感觉在这种条件下TDD搞起来好像不太合适，但是TDD确实也是保证质量的一个很好的途径。不晓得群里的大侠们有没有相关的
经验可以共享下？
Mikster.Z
zhangyingneng
jinhu wang
sagasw
软件开发中单元测试unit testing
http://sunxiunan.com/?p=750
浅论C++在Windows下的GUI自动测试（Unit Test）
水平所限，只是谈论的很浅显，仅做参考抛砖引玉了。
------------------------------------------
blog: http://sunxiunan.com/
C++, Lua, living in Dalian
http://twitter.com/sagasw
------------------------------------------
2010/9/25 Robin <robino...@gmail.com>:
Robin
且很多后续的操作也是基于这些和系统交换的操作上的吧。如果这些都用打桩来实现，那不是工作量相当巨大。
On Sep 25, 11:18 am, zhangyingneng <zhangyingn...@gmail.com> wrote:
> 看看cppunit的作者是怎么定义unittest的.
>
> Here are qualities of good unit tests:
>
> They run fast.
>
> They help us localize problems.
>
> A unit test that takes 1/10th of a second to run is a slow unit test.
>
> Unit tests run fast. If they don't run fast, they aren't unit tests.
>
> Other kinds of tests often masquerade as unit tests. A test is not a unit
> test if:
>
> It talks to a database.
>
> It communicates across a network.
>
> It touches the file system.
>
> You have to do special things to your environment (such as editing
> configuration files) to run it.
>
> 2010/9/25 Mikster.Z <chinamix...@gmail.com>
>
>
>
> > 可以做个测试框架，把系统调用的函数在pc上做模拟，在PC上TDD。
Mikster.Z
liuxinyu
如果在国内，有大量廉价的test团队，你可以有组织的进行大规模人肉test，有时发现总成本竟然比你重头写stub,各种dummy模块，录制UI
实现等等还要便宜，省时间。
当然，这种人肉test是很系统的。有一个defect tracking system再加人肉。在国内这个奇特的环境下，竟然很好用。
另外GUI auto test的话，我曾经觉得MIT的sikuli会是个好工具。不知道有没有哪位这么玩过。
Xu Yi
UT是指代码级别的测试，其标准是在编译时就可以执行所有的UT测试用例。例如使用JUnit测试Java代码。当然为了使UT在编译时即可以运行，会需要改进代码的结构，让他们能够符合SRP（单一职责原则）等原则，必要的时候要通过Mock等方式来隔离测试对e.g.数据库的访问。
TDD更多的是指一种开发的方式。有别于以往先开发完一大段、一大片的代码，编译成功之后，才去撰写相关的测试用例（通常是模块测试，需要在实际环境上运行，有别于单元测试）的方式，TDD指的是在开始敲入代码之前，先写出测试用例，运行该测试用例（尚无任何代码），测试用例运行失败，而后才添加仅需的代码使这个测试用例通过。而后再添加下一个测试用例。当然此处所指的测试用例是指代码级别的测试用例，也即UT（单元测试）。
可以认为是，要写UT不一定要用TDD，但是要用TDD，基本上肯定会（或，必须得）使用UT。
--
- - - - - - - - - -
Xu Yi, Kaverjody
Agile Coach.CSP
Test Automation Coach
Blog : http://damianji.spaces.live.com
- - - - - - - - - -
Bruce Dou
2010/9/25 liuxinyu <liuxi...@gmail.com>
A decathlon Drupal developer & programmer
http://blog.eood.cn/
z.cHris
--
Best regards,
Chris
Robin
还有一个问题是这些stub mock之类的东西，很有可能在以后也是会变的呀，那么以后重构的话，其实这个也是需要跟着重构的。
On Sep 26, 9:47 am, "z.cHris" <chris.d.ch...@gmail.com> wrote:
> 测试包含好多方面，比如功能测试，集成测试等，你所说的我们有廉价的test团队，用在这些地方是没问题的，大规模的人肉测试，让我想到了Exploring
> test，但这个测试对人的要求也不低。
>
> 对于这个Topic提到的TDD，我觉得更多的是针对于代码级的，也就是程序员自己为了代码的正确性以及以后的可重构性所进行的工作，一般来说两份代码应该是同 一人写的。
>
> 一般TDD分为四个步骤：
> 1. 写一个failed test case
> 2. 写一段code
> 3. 执行test case，直至通过，如果failed，更改code。
> 4. 重构。
> 1.
> ...
>
> @Robin
> 提到的些那些系统调用是可以通过stub或者mock来实现的，至于花费的时间，相比于日后万一（估计是一定）需要重构时所花费的时间来讲是小菜一碟。
>
> 不过如果大家都没有完全接受TDD，仅仅是管理层一厢情愿的推行，慢慢的最后有可能就成了尴尬的"UT覆盖率超过80%"之类了。这个不是真正意义上的TDD， 我觉得是被UT。
> :-)
>
> 分享两篇文章：
>
> The Four Elements of Simple Designhttp://blog.jbrains.ca/permalink/the-four-elements-of-simple-design
>
> Writing Unit Tests Is Your Job, So Quit Making Excuseshttp://regulargeek.com/2010/08/13/writing-unit-tests-is-your-job-so-q...)
>
> 2010/9/25 liuxinyu <liuxiny...@gmail.com>
Mikster.Z
Dong Zheng
--
liuxinyu
我抛块砖。
我当年年轻时读Kent Beck的英文版Test Driven developing, 和eXtreme Programming,
embrace the changes时，也曾经热血沸腾。
但是经过了这些年，我现在反思了，TDD真的像书上所说能带来高质量代码么？（Eric Gammer赞同TDD提高代码质量一说，但是他本人是
Kent的
pair programming搭档，故而其票打了折扣）
从2007年到现在我所在的公司一直在做agile/scrum，但是经过我的观察，我认为最重要的是人，而不是方法论。
正如Brooks Friedrich在35年前说的，没有银弹(sliver bullet)。再过十年，也许有更新的方法论被业界追捧，当做另外一
个银弹。
我的判断是TDD也许在某种程度上提高代码的质量，但是有两个前提：
1, 做TDD的人（开发人员），以前不做TDD；真正在背后起作用的是思维习惯的转换，而不是TDD。思维习惯的转换真正提高了代码的质量，不过这一
定是短期的。长期做TDD的话，就形成了新的思维习惯，于是代码质量就不会继续提高了。
2，TDD的对象问题是业务问题，而不涉及科学研究，包括算法和数学。用TDD难以发现（发明？）快速排序这样的算法。算法问题和科学研究的思维方式和
TDD冲突。
TDD也许擅长解决复杂的对象系统的编程问题，但是最重要的还是人。倒退若干年，没有敏捷，没有TDD，一样有好的代码出现，Knuth, John
Bentley, 这样的人
用任何方法论和流程都能写出很棒的程序。80%做瀑布模型开发出问题的人，即使换成敏捷流程一样会出问题。
HaoPeiQiang
我认为最重要的是人，而不是方法论，没错，也是废话
别的不论，项目代码足够多以后，重构，或者说任何修改，都要有unit test来保证，不然不要扯好的代码，能保证不出错的难度会越来越大。
2010/9/26 liuxinyu <liuxi...@gmail.com>:
--
Tinyfool的开发日记 http://www.tinydust.net/dev/
代码中国网 http://www.codechina.org
myTwitter: http://twitter.com/tinyfool
smart.mk1
个人认为TDD是迭代螺旋里原型构建活动与单元测试的结合.
通过unit test和mock框架使原型构建的过程标准化, 实现上变得简单, 也降低了理解上的难度("不就是做单元测试嘛"之类的), 另外, 在使用原型验证设计的同时, 产出了单元测试代码.
这些能够提高生产率的地方才是TDD的魅力.
Dong Zheng
以及哪个地方是会跟TDD相矛盾的？
--
Best regards,
Chris
jigsaw
kent beck和martin fowwer鼓吹的那一套体系试图把开发MIS的经验泛化到所有代码工作中，走的是卖狗皮膏药和大力丸的路线
On Sep 26, 10:37 am, HaoPeiQiang <HaoPeiQi...@gmail.com> wrote:
> 没有银弹(sliver bullet)，没错，但是是废话
> 我认为最重要的是人，而不是方法论，没错，也是废话
>
> 别的不论，项目代码足够多以后，重构，或者说任何修改，都要有unit test来保证，不然不要扯好的代码，能保证不出错的难度会越来越大。
>
> 2010/9/26 liuxinyu <liuxiny...@gmail.com>:
HaoPeiQiang
2010/9/26 jigsaw <jig...@gmail.com>:
jigsaw
我估摸着做研究工作的要有开放的思路，要反复试错，要有创新的勇气。
而tdd的本质是，不错就是胜利，所以一上来就划道红线，出线就是违规，还搞些可见的红色的banner让人望而生畏。这不就是在第一时间扼杀创新吗？
2010/9/26 Dong Zheng <chris...@gmail.com>
Xu Yi
测试包含好多方面，比如功能测试，集成测试等，你所说的我们有廉价的test团队，用在这些地方是没问题的，大规模的人肉测试，让我想到了Exploring test，但这个测试对人的要求也不低。
是Exploratory Testing，和Acceptance Testing相对应，被认为是敏捷测试的一部分。 关于ET，大家可以去搜索James Bach以及Cem Kaner的一些文章、演讲之类的，或者附件是我的一份材料，也可以看看。关于敏捷测试整个事情，可以去看Lisa Crispin和人合著的《Agile Testing》一书，还可以跟踪Elisabeth Hendrickson的博客、演讲等，Elisabeth可是今年Golden Paska奖的获得者哦。
Exploratory Testing和人肉测试或者说手工测试不能划等号的，更详细的信息可以看看一份材料“The Nature of Exploratory Testing - Cem Kaner & James Bach”.
jigsaw
Bruce Dou
Xu Yi
如果你认为没有营养，那么大可以敲个delete，也或者以后看到我发的东西一笑而过。
如果你愿意给些建议，那么不妨稍微写几句为什么没有营养，以及给点建议如何让它变得更有营养，发给我。
-徐毅
Xu Yi
jigsaw
Xu Yi
>>并非给人打广告，徐毅就是我自己我就是说你给自己打广告>>这是我在公司内部做培训时使用的材料不能因为是你自己写的，就意味着你可以随意发布>>如果你愿意给些建议，那么不妨稍微写几句为什么没有营养我只给评论，不给建议，行吗？
除了只评论部建议，你还有不看的自由。请三思。