|
锁定老帖子 主题：TDD很痛苦
精华帖 (0) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (0)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2010-09-01
xyz20003 写道 DBUnit给我们带来的问题是，它不能自动处理外键关系，表间关系复杂时，每次insert都会报错失败。请问有何解决方案？
DBUnit还有个问题，你在自己测试中插入的数据（而非配置在文件中的）它是不会帮你删的。 正是应该以上原因，我们的数据框架是自己写的。 setup用SQL，自己保证顺序 tearDown后台跑一个存储过程，清空所有表 |
| 返回顶楼 | |
|
发表时间：2010-09-01
说不痛苦的， 有几个在系统里有百万行以上代码的？
|
| 返回顶楼 | |
|
发表时间：2010-09-01
frostred 写道 做TDD其实并不痛苦。但学TDD真的是可能很痛苦。
学TDD最好的方法是和高手一起做Pair Programming。如果没有这个条件呢，那你也只能忍着痛苦，摸索着前进了。 以下有几点建议，希望能对你有所帮助。 1. 给自己多一点时间，比如说计划用一两年的时间掌握TDD，而不是一两个月。 2. 不要太强迫自己按照某种固定的套路来。如果某些Unit Testing太难做，就不要做了。 3. 如果觉得测试优先太痛苦，那就先写代码，后写测试。写好的测试，也是需要一个学习过程的。当你觉得对写测试有信心的时候，再试着改变次序，也未尝不可。 4. 学习TDD，关键其实是学习object oriented programming。因为TDD的关键不是为写出最牛B的测试代码，而是要写出最容易测试的代码。最容易测试的代码在绝大多数场合下和好的object oriented代码的标准是相一致的。 5. TDD不是Refactoring的必要条件。不要把Refactoring想得太神秘了，说白了，它不过是，把虽然能正常工作，但写得不好的代码改的更好一点而已。所以，觉得要做Refactoring的时候，一定做，不要管有没有测试代码。因为做Refactoring，是学习object oriented programming 的最好方法之一。 6. 做TDD Kata 很有乐趣，也很有帮助。http://codingdojo.org/ 点击KataCatalogue 7. 循序渐进，享受学习的过程。就象开车去一个地方，别总想着目的地，享受沿途的风景也很重要。 这个方法不错，可以尝试使用。。。 |
| 返回顶楼 | |
|
发表时间：2010-09-01
今天和我们头交换了一下想法，觉得DDD + TDD是比较合适的组合。
我们现在使用的贫血模型——大量的业务操作都通过执行相应的sql操作，service层做的事情很少，更多的是delegate给了dao层去直接执行sql语句。这样代码重用是很低的。这同样也给准备数据造成了比较大的困难。不过我重新整理了一下测试代码，抽取出来一些共用的方法——比如生成一个对象等类似的方法，现在测试代码清爽多了。 frostred 说的有道理。我接触TDD时间比较短，更多的是接受它的一个思想，觉得挺不错。但是真正使用TDD还有许多东西需要掌握。 现在比较疑惑的是现在在Driven设计的时候实际上我们有了一个前提——这个业务逻辑一定要放在我们domain的java代码里，但是有时候（或者说很可能）将部分业务逻辑，比如某些业务规则的检测放在前端的页面上似乎更合适，也更易于实现。这个时候我发现我从头就错了，因为这部分逻辑没有被放到domain层。 这是不是说我的经验还不够？貌似现在为了友好性，许多业务检测都放到了前端，所以应该不止是我遭遇这个问题把 ps：有时间找两本书看看。 |
| 返回顶楼 | |
|
发表时间：2010-09-02
友好型不一定什么校验都要放在前端啊。
你是说前端的javascript校验来实现？ 如果有必要，也可以都做成domain里面的校验，用ajax来提高友好性。。。 这个主要是看校验本身应该是放在那一层的吧 |
| 返回顶楼 | |
|
发表时间：2010-09-02
真正的tdd，理念还是很超前的。建议大家可以先从单元测试做起。先一点一点的补充最核心业务的核心单元测试用例。然后后面逐步完善。
|
| 返回顶楼 | |
|
发表时间：2010-09-02
最后修改：2010-09-02
玩TDD，粒度也很重要。
太细会浪费时间，大量的测试代码只会掩盖重要的测试代码. J2EE的项目都会依赖很多包，对这样的包方法没有必要进行TDD.因为这些方法都是验证过了的，不可能有问题。 要TDD的是你项目中本身的业务方法，并且要严格遵守TDD的小步推进，快速构建的思路 |
| 返回顶楼 | |
|
发表时间：2010-09-02
blackchoc 写道 今天和我们头交换了一下想法，觉得DDD + TDD是比较合适的组合。
我们现在使用的贫血模型——大量的业务操作都通过执行相应的sql操作，service层做的事情很少，更多的是delegate给了dao层去直接执行sql语句。这样代码重用是很低的。这同样也给准备数据造成了比较大的困难。不过我重新整理了一下测试代码，抽取出来一些共用的方法——比如生成一个对象等类似的方法，现在测试代码清爽多了。 ps：有时间找两本书看看。 这不是TDD的问题，而是贫血模型的问题。贫血模型把对象的属性和操作分开，就是希望domain object尽量稳定，而把易变的操作单独隔离开来，这就不符合OO 封装的基本要求。而TDD会push你去把整理责任，分给对象，自然会不舒服了 |
| 返回顶楼 | |
|
发表时间：2010-09-02
blackchoc 写道 今天和我们头交换了一下想法，觉得DDD + TDD是比较合适的组合。
我们现在使用的贫血模型——大量的业务操作都通过执行相应的sql操作，service层做的事情很少，更多的是delegate给了dao层去直接执行sql语句。这样代码重用是很低的。这同样也给准备数据造成了比较大的困难。不过我重新整理了一下测试代码，抽取出来一些共用的方法——比如生成一个对象等类似的方法，现在测试代码清爽多了。 frostred 说的有道理。我接触TDD时间比较短，更多的是接受它的一个思想，觉得挺不错。但是真正使用TDD还有许多东西需要掌握。 现在比较疑惑的是现在在Driven设计的时候实际上我们有了一个前提——这个业务逻辑一定要放在我们domain的java代码里，但是有时候（或者说很可能）将部分业务逻辑，比如某些业务规则的检测放在前端的页面上似乎更合适，也更易于实现。这个时候我发现我从头就错了，因为这部分逻辑没有被放到domain层。 这是不是说我的经验还不够？貌似现在为了友好性，许多业务检测都放到了前端，所以应该不止是我遭遇这个问题把 ps：有时间找两本书看看。 业务检测在前端和后端都做校验,提高安全性. |
| 返回顶楼 | |
|
发表时间：2010-09-02
xyz20003 写道 DBUnit给我们带来的问题是，它不能自动处理外键关系，表间关系复杂时，每次insert都会报错失败。请问有何解决方案？
DbUnit确实不能自动处理外键关系。这就需要你在组织数据集文件（一个.xml）时，要注意多个<table></table>之间的顺序。例如表B依赖表A，你要先写<table name="A"></table>，再写<table name="B"></table>。这是insert数据时要注意的。 当运行完测试用例后，要清理数据时，也要注意依赖关系。 你会问，当关联关系复杂时，如何办？DbUnit有一个类，可以输出多个表之间的依赖关系树。看着这个“依赖关系树”再组织数据集文件时，就游刃有余了。 |
| 返回顶楼 | |
