|
锁定老帖子 主题：你们公司单元测试吗?
精华帖 (0) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (0)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2006-01-17
robbin 写道 刚刚看了一下Spring的jdbc和hibernate部分的testcase，果然没有使用数据库，大量运用easymock，纯粹的单元测试。
而我平时惯常使用的测试方法(即在setUp里面启动Spring容器和HSQLDB In-Memory)那根本就不叫单元测试，而应该叫做集成测试了。这种方式每个Test完成之后都必须关闭Spring容器和HSQLDB，每个Test之前都必须独立初始化数据，以保证Test之间的独立性，我早就觉得这种方式运行测试集未免太慢了点，看来是自己把集成测试当单元测试用了。 然后又看了一下Hibernate的testcase，是连接HSQLDB，每次test都重建SessionFactory去测试的，和我采用的方法大同小异。这样来看，对于我们平时使用的Hibernate/Spring/Webwork来说，单元测试方案是不是可以这样来制订： 如果业务bean基本上就是持久化逻辑，那么就应该采用像Hibernate那种方式测试，当然考虑到我们使用Spring封装了Hibernate，所以仍然要启动spring容器和HSQLDB来测试业务bean。 如果业务bean还包含商业运算逻辑，那么就应该使用DAO接口分离持久化逻辑，使用Mock对象替换DAO实现，单独测试商业运算逻辑。 对于Web Action，不应该直接使用业务bean，而应该提供Mock对象，以单独测试Action工作是否正常。 我在使用mock object当中，感觉到mock object最大的好处是对基础框架的测试上。 基础框架不需要和具体的数据相关，只关心流程。举个例子，我对JdbcTemplate做测试，任何操作，因为sql语句都是客户端构造，错与对和template无关，我只需要保证JdbcTemplate操作数据库的流程没有错误就可以。 相反，测试Dao(此Dao使用JdbcTemplate)就不合适引入mock,因为，本身测试就是操作DB,极端可以认为验证是sql语句的正确性。 |
| 返回顶楼 | |
|
发表时间：2006-01-18
公司环境根本没办法把测试进行下去。
看来换工作是势在必行。 
其实，你自己测试了不说明问题， 你的团队测试了吗？ |
| 返回顶楼 | |
|
发表时间：2006-01-18
zkj_beyond 写道 公司环境根本没办法把测试进行下去。
看来换工作是势在必行。
其实，你自己测试了不说明问题， 你的团队测试了吗？ 应该可以这么说,你在的公司重视质量吗?有没有建立健康的质量文化?有做长久生意,质量工程是必须重视的,当然不光是测试来保证质量. 大概来说,传统的测试是post-process,也就是通过独立的事后测试来保证产品代码的质量,然后引入一些过程中的评审来保证开发时的质量.但是这样是远远不够的,因为你怎样来保证设计,保证需求的质量呢? 很幸运,XP把这些好的实践都涵盖了,pair programming实际上是一种灵活高效的评审,TDD是用测试手段来保证需求和设计的质量,而持续集成和TDD积累的测试用例,保证了独立的事后测试的有效性 --- 接收测试的一部分? 这些手段都体现了反馈这个核心价值. |
| 返回顶楼 | |
|
发表时间：2006-01-18
robbin 写道 单元测试应该关注一个类的单一职责，按照这样的方式，例如我要测试一个Spring的bean，就必须隔离Hibernate的影响和数据库的影响，因此我必须编写大量的mock对象和stub对象来模拟接口行为，但是这样的模拟测试意义有多大呢？
我感觉，如果我们编写一个通用软件框架，或者软件产品，这么细粒度的单元测试有其必要，但是对于一般的应用软件来说，这么细粒度单元测试有必要吗？我感觉只写那些集成单元测试似乎就足够了。 我同意上面的观点，曾尝试隔离各个模块之间的影响，但是花在mock上面的时间很多，而且有时候达不到要的效果。但是，mock后的单元测试效率当然是无比之高。不过个人认为代价较大，这个与系统本身的复杂度可能有关系，更大程度与我的技术水平有关系。 所以现在我使用的还是集成单元测试，而集成单元测试我觉得难点就在测试背景的建立（就是各种各样的基础数据以达到组合成你能想到的Usecase） 不过我这里有一个疑问，到底上面所说到的需要隔离的单元测试其实是针对多小粒度的类？我工作中一般是针对每个业务实体来写单元测试。 |
| 返回顶楼 | |
|
发表时间：2006-01-18
robbin 写道 刚刚看了一下Spring的jdbc和hibernate部分的testcase，果然没有使用数据库，大量运用easymock，纯粹的单元测试。
而我平时惯常使用的测试方法(即在setUp里面启动Spring容器和HSQLDB In-Memory)那根本就不叫单元测试，而应该叫做集成测试了。这种方式每个Test完成之后都必须关闭Spring容器和HSQLDB，每个Test之前都必须独立初始化数据，以保证Test之间的独立性，我早就觉得这种方式运行测试集未免太慢了点，看来是自己把集成测试当单元测试用了。 然后又看了一下Hibernate的testcase，是连接HSQLDB，每次test都重建SessionFactory去测试的，和我采用的方法大同小异。这样来看，对于我们平时使用的Hibernate/Spring/Webwork来说，单元测试方案是不是可以这样来制订： 如果业务bean基本上就是持久化逻辑，那么就应该采用像Hibernate那种方式测试，当然考虑到我们使用Spring封装了Hibernate，所以仍然要启动spring容器和HSQLDB来测试业务bean。 如果业务bean还包含商业运算逻辑，那么就应该使用DAO接口分离持久化逻辑，使用Mock对象替换DAO实现，单独测试商业运算逻辑。 对于Web Action，不应该直接使用业务bean，而应该提供Mock对象，以单独测试Action工作是否正常。 是这样的,分层中各层测试的目的不一样,WEB层主要完成路径的测试,Service层完成逻辑测试,而DAO才是测试与数据库操作的正确性. 带着这个目的,你就不会写出一个Web的Action测试就将Service,DAO通通测试过的Testcase,从而来否定如DAO的测试是否需要,因为Action都通过了就成事大吉了嘛! |
| 返回顶楼 | |
|
发表时间：2006-01-18
Without EJB的第十四章Unit Test真的不错，虽然我还没有开始改我原有的Unit Test代码，不过已经明白我原来测试代码mock部分的缺点了。
|
| 返回顶楼 | |
|
发表时间：2006-01-18
gigix 写道 robbin 写道 我现在觉得：如果不施行TDD，就很难写出来高质量的单元测试，似乎看起来TDD是施行有效单元测试的一个必要前提。
我随便举个例子。譬如说以前potian就讲，没有大量工厂的程序不是好程序（当然，那是在IoC容器流行之前）。后来IoC容器流行了，我说过一句“程序代码里不应该有new操作”（主要是针对带有业务逻辑的对象而言）。就有人问了，为什么一定要用创建型模式？为什么不能new UserManager()非要ManagerFactory.getUserManager()或者依赖注射？然后大家讨论来讨论去，三天讨论不出结果。 那么当你用TDD的时候怎么样？你马上就想mock UserManager，但是如果你在代码里写new UserManager()你就mock不了，你就得费老鼻子劲去写这个单元测试。所以你就改变实现方式，用一个工厂，然后先mock这个工厂。这事情很奇妙，我也说不出它理论上到底是怎么回事，但事实就是这样：紧耦合的坏设计会让你写不出单元测试，所以你就会自然而然的采用松耦合的设计——甚至你写完了还没有意识到这一点。 很赞同这个观点,不应该从传统测试的角度思考TDD.而应该尽量从设计的角度 Please don't think about TDD as testing, because if you do, you're missing the point. 下面是一个tss上的一个帖子: The real benefit of TDD is the design process. With TDD and refactoring, a design can emerge in a positive direction as the test cases are first class users of the code. This requires the code that is under development to be well constructed and modular to allow for this to happen, and not the "standard" unit testing of "set up the container, run some end-to-end tests and pat yourself on the back". |
| 返回顶楼 | |
|
发表时间：2006-04-10
有专门的测试人员，代码由开发人员提交给测试人员，后者按照测试用例测试
我原来呆的公司是这样的做法。当时是给华为做的一个项目。我建议每个人都编写JUnit，测试通过。然后CVS commit。被其他的开发人员一直否决，说工作量太大，这不是给自己找麻烦吗？无语，继续做。 然后提交给华为验收，然后两三轮反馈和Debug，就通过了。其实那个项目光我们这边知道的Debug还有很多呢。后来闹了很多笑话，不表。 前几天刚读完《单元测试之道 --Java版》现在的感悟是TDD，编写单元测试真的是很重要的事情。这才是正确的软件开发的路子嘛。不过似乎国内来说，大部分的公司都没采用吧。我想了想，可能是这种文化还不够流行吧。没有引起足够的重视。 现在的项目是标准的基于Appfuse的项目，boss说如果自己愿意可以编写unit case，不过似乎我还是偷懒没怎么写过-_-### 我也非常同意firebody的看法：单元测试的编写水平可以反映一个人的OO编程水平高低。 |
| 返回顶楼 | |
|
发表时间：2006-04-12
这和博士硕士没关系, 只和 程序写得多写得少有关系.
|
| 返回顶楼 | |
|
发表时间：2006-05-24
stone 写道 单元测试不仅仅是公司的事情,这是一个好的个人习惯
我再帮你换下这句话 “单元测试不仅仅一个好的个人习惯，而是公司的事情。” 因为我发现好多公司主要还是领导层没有认识到测试的重要性，他们给我们的感觉是迟钝、呆板、默守成规。相反有许多的开发人员，特别是一些能力比较强，喜欢接收新事务的开发人员，一直在锲而不舍的使用业务的一些好的方法和好的技术。 |
| 返回顶楼 | |
