- 浏览: 274747 次
- 性别:
- 来自: 尤溪
文章分类
最新评论
-
palytoxin:
我现在也发现是这样
关于分享 -
float2net:
Java社区,分享有利于提高。
关于分享 -
hz_qiuyuanxin:
头晕啊,啊邱
RSpec学习笔记 -
reyesyang:
...
关于分享 -
Hooopo:
一般实现map都先实现each
在 Ruby 中对树状结构(tree)进行 map 操作
回头看了看。。本篇纯属误导人之作。
我正在学TDD,这算是自己做的一个小玩具吧,练手用而已。
我打算做一个Blog,一个Blog的主要功能也就是:保存Blog、删除Blog、查看Blog。OK,先上TODOLIST:
然后是测试代码,测试保存BLOG:
我需要一个Blog,一般Blog都会有标题、内容、创建时间:
BlogService里的业务逻辑很简单,就是调用DAO保存Blog。有人说调用DAO保存Blog算什么业务逻辑,那只是对Blog的持久化。可是我觉得,在博客这个“领域”,保存一篇博客算是一个业务逻辑吧?只是这个业务逻辑非常简单,我只要测试这个动作有没被执行就可以了。
在gigix的什么是“测试驱动开发”中见robbin说replay()前面是详细设计,后面是需求文档,当时没太理解,现在看看代码好像真是这么回事。
现在的测试代码编译不了,需要实现一个Blog:
一个BlogDAO接口,声明一个save(Blog blog)方法:
一个BlogService接口,声明一个save(Blog blog)方法、一个setBlogDAO(BlogDAO blogDAO)方法:
最后导入Spring包,现在测试代码编译通过,但是测试通不过,红条。抛的异常是NullPointerException,找了一会原因,发现还没配置BlogService的实现类,于是写了个BlogService的实现类如下,并在spring配置文件中配上:
由于业务逻辑非常简单(调用dao持久化blog),所以我就不先运行Test,等看见红条后再来修改Service的实现。大步一点,我直接把方法给写完整了:
最后我觉得应该可以了,运行测试,绿条,通过了,一个功能就完成了。代码很简单,也没什么要重构的。现在划掉TODOLIST上的“保存BLOG”,接下来是“删除BLOG”。
TODOLIST:
先到这吧,整个过程都是我在自以为是,呵呵。
我想请教论坛里的前辈,这整个过程有没什么问题?
还有单元测试中,Spring是不是这么用的(applicationContext.getBean(beanName))?
希望多多批评,谢谢了!
我想我是从一开始就错了。为什么要从Service开始?按你的说法,为什么要从DAO开始?
=========================================
主帖中我的问题,我自己来回答一些:
如何针对接口测试?JUnit中如何使用Spring?可以搜索关键字:AbstractJUnit4SpringContextTests。
至于从哪里开始写测试,这是我的一些思考:http://yuan.iteye.com/blog/312118,由于目前对DDD领悟得还不到位,可能还有些没考虑到的问题。希望最好有人指点一下。
异常?比如说?
我觉得这么简单的逻辑不包含异常情况吧。你是指Runtime Exception吗?
我觉得业务代码中如果可能抛出业务意义上的异常,就专写个方法测试可能抛出的CatchedException,其余非业务上的异常中如果有CatchedException(一般不会有这种情况,我都会封装成RuntimeException)就直接封装成RuntimeException抛出。
我正在学TDD,这算是自己做的一个小玩具吧,练手用而已。
我打算做一个Blog,一个Blog的主要功能也就是:保存Blog、删除Blog、查看Blog。OK,先上TODOLIST:
引用
保存BLOG
删除BLOG
查看BLOG具体内容
删除BLOG
查看BLOG具体内容
然后是测试代码,测试保存BLOG:
/** * 测试保存BLOG */ @Test public void testSaveBlog(){ blogService.save(blog); }
我需要一个Blog,一般Blog都会有标题、内容、创建时间:
/** * 测试保存BLOG */ @Test public void testSaveBlog(){ Blog blog = new Blog(); blog.setTitle("title"); blog.setContent("content"); blog.setCreatedTime(new Date()); blogService.save(blog); }
BlogService里的业务逻辑很简单,就是调用DAO保存Blog。有人说调用DAO保存Blog算什么业务逻辑,那只是对Blog的持久化。可是我觉得,在博客这个“领域”,保存一篇博客算是一个业务逻辑吧?只是这个业务逻辑非常简单,我只要测试这个动作有没被执行就可以了。
public class BlogServiceTest extends BaseTest { private BlogService blogService; private BlogDAO blogDAO; public void setBlogService(BlogService blogService){ this.blogService = blogService; } @Before public void setUp(){ this.blogService = (BlogService)this.applicationContext.getBean("blogService"); blogDAO = createMock(BlogDAO.class); this.blogService.setBlogDAO(blogDAO); } @After public void tearDown(){ verify(blogDAO); } /** * 测试保存BLOG */ @Test public void testSaveBlog(){ Blog blog = new Blog(); blog.setTitle("title"); blog.setContent("content"); blog.setCreatedTime(new Date()); blogDAO.save(blog); replay(blogDAO); blogService.save(blog); } }
在gigix的什么是“测试驱动开发”中见robbin说replay()前面是详细设计,后面是需求文档,当时没太理解,现在看看代码好像真是这么回事。
现在的测试代码编译不了,需要实现一个Blog:
public class Blog { private String id; private String title; private String content; private Date createdTime; //Setter }
一个BlogDAO接口,声明一个save(Blog blog)方法:
public interface BlogDAO { /** * 保存Blog * @param blog 要保存的Blog */ void save(Blog blog); }
一个BlogService接口,声明一个save(Blog blog)方法、一个setBlogDAO(BlogDAO blogDAO)方法:
public interface BlogService { /** * Set DAO * @param blogDAO */ void setBlogDAO(BlogDAO blogDAO); /** * 保存Blog * @param blog 要保存的Blog */ void save(Blog blog); }
最后导入Spring包,现在测试代码编译通过,但是测试通不过,红条。抛的异常是NullPointerException,找了一会原因,发现还没配置BlogService的实现类,于是写了个BlogService的实现类如下,并在spring配置文件中配上:
public class BlogServiceImpl implements BlogService { @Override public void save(Blog blog) { // TODO Auto-generated method stub } @Override public void setBlogDAO(BlogDAO blogDAO) { // TODO Auto-generated method stub } }
由于业务逻辑非常简单(调用dao持久化blog),所以我就不先运行Test,等看见红条后再来修改Service的实现。大步一点,我直接把方法给写完整了:
public class BlogServiceImpl implements BlogService { private BlogDAO blogDAO; @Override public void save(Blog blog) { blogDAO.save(blog); } @Override public void setBlogDAO(BlogDAO blogDAO) { this.blogDAO = blogDAO; } }
最后我觉得应该可以了,运行测试,绿条,通过了,一个功能就完成了。代码很简单,也没什么要重构的。现在划掉TODOLIST上的“保存BLOG”,接下来是“删除BLOG”。
TODOLIST:
引用
保存BLOG
删除BLOG
查看BLOG具体内容
删除BLOG
查看BLOG具体内容
先到这吧,整个过程都是我在自以为是,呵呵。
我想请教论坛里的前辈,这整个过程有没什么问题?
还有单元测试中,Spring是不是这么用的(applicationContext.getBean(beanName))?
希望多多批评,谢谢了!
评论
7 楼
抛出异常的爱
2009-01-09
写什么没顺序.
PS你写多了就会对DAO+SERVICE这种一对一的东西厌恶了.
一般会三到五个dao对应一个service
强大的mock+junit的确让人改起代码来得心应手.
PS你写多了就会对DAO+SERVICE这种一对一的东西厌恶了.
一般会三到五个dao对应一个service
强大的mock+junit的确让人改起代码来得心应手.
6 楼
yuan
2009-01-09
风花雪月饼 写道
测试步骤错了吧。。
先测试DAO。。。然后再写Service测试。。。
先测试DAO。。。然后再写Service测试。。。
我想我是从一开始就错了。为什么要从Service开始?按你的说法,为什么要从DAO开始?
=========================================
主帖中我的问题,我自己来回答一些:
如何针对接口测试?JUnit中如何使用Spring?可以搜索关键字:AbstractJUnit4SpringContextTests。
至于从哪里开始写测试,这是我的一些思考:http://yuan.iteye.com/blog/312118,由于目前对DDD领悟得还不到位,可能还有些没考虑到的问题。希望最好有人指点一下。
5 楼
风花雪月饼
2009-01-09
测试步骤错了吧。。
先测试DAO。。。然后再写Service测试。。。
PS:我非常讨厌DAO和Service.
先测试DAO。。。然后再写Service测试。。。
PS:我非常讨厌DAO和Service.
4 楼
pipilu
2008-10-28
他的方法声明中并没有声明会抛出异常,所以也不必测这种情况了
3 楼
WhisperXD
2008-10-25
e..我个人理解的TDD没啥复杂的东西。。
说白了就是结果驱动咯。
也就是说你先设计出使用到最后会发现的各种可能的结果,并且用junit写出这些结果的junit表示。然后开始编程。
有的放矢,让你从一个使用者+实现者的混合角色变为先从使用者角色设计程序的结果期望,然后再变为实现者去实现他们,这样比较不容易出漏洞,并且效率更高。
那么在我的这种肤浅的认识下。
我认为所有在你处理中会抛出的各种异常,比如ilegalargument啊这些,还有SQL异常啊。等等都做过处理给出正确的反映才是真正一个程序应该做到的。
说白了就是结果驱动咯。
也就是说你先设计出使用到最后会发现的各种可能的结果,并且用junit写出这些结果的junit表示。然后开始编程。
有的放矢,让你从一个使用者+实现者的混合角色变为先从使用者角色设计程序的结果期望,然后再变为实现者去实现他们,这样比较不容易出漏洞,并且效率更高。
那么在我的这种肤浅的认识下。
我认为所有在你处理中会抛出的各种异常,比如ilegalargument啊这些,还有SQL异常啊。等等都做过处理给出正确的反映才是真正一个程序应该做到的。
2 楼
yuan
2008-10-25
WhisperXD 写道
bean基本就这么用么。其实怎么用看你自己的需要咯
单元测试只有一个么?。。。异常情况不需要测试么?。。。e。。。
单元测试只有一个么?。。。异常情况不需要测试么?。。。e。。。
异常?比如说?
我觉得这么简单的逻辑不包含异常情况吧。你是指Runtime Exception吗?
我觉得业务代码中如果可能抛出业务意义上的异常,就专写个方法测试可能抛出的CatchedException,其余非业务上的异常中如果有CatchedException(一般不会有这种情况,我都会封装成RuntimeException)就直接封装成RuntimeException抛出。
1 楼
WhisperXD
2008-10-25
bean基本就这么用么。其实怎么用看你自己的需要咯
单元测试只有一个么?。。。异常情况不需要测试么?。。。e。。。
单元测试只有一个么?。。。异常情况不需要测试么?。。。e。。。
发表评论
-
我也有自己要做的事!
2012-11-27 22:40 15管理人员似乎总会在看 ... -
一个讨论反模式
2011-09-17 15:14 1887症状: DB网员工A:我们应该这么做。 DB网员工B:为什么呢 ... -
对TDD/BDD的一些理解
2010-10-13 08:35 0以下内容均为我自己对T ... -
TDD/BDD问与答。
2010-09-08 11:44 0gigix ——什么是测试驱动开发: 看“测试驱动开发”这个 ... -
谈谈性能
2010-05-18 15:58 0以下言论收集于javaeye论 ... -
伪代码法
2010-04-25 19:16 25022011-05-11 补充一个链接 ... -
Behaviour Driven Rails(瞎翻译。附原文。)
2010-03-04 20:27 1347晚上看到这个链接:http://ywencn.iteye.co ... -
点点滴滴
2010-01-23 23:21 0长度超过1个的链式调用经常可以封装起来,例如: 在contro ... -
聊天记录,放这记一下。
2010-01-03 16:59 0(15时24分08秒) Kadvin: 其实写Test Cas ... -
o6z说code review
2009-12-17 12:38 1645ozzzzzz在agilechina上 写道 ... -
意外收获,关于mock和stub。
2009-09-17 14:25 10236记录一些自己的想法, ... -
从AWDWR中的depot思考软件设计
2009-08-18 17:52 1400一般对购物车简单的描述会是这样的(其实就是AWDWR中的那个d ... -
回复: 以截拳道看"太极模式"
2009-04-13 01:51 272wendong007 写道我们编程的时候不要老想着这样那样的模 ... -
回复: 我对针对接口编程的浅解
2009-03-30 00:18 1221其实吧,接口这东西。。我举个例子来说,你如果正在写业务代码,考 ... -
“山寨”框架3宗罪
2009-03-22 23:44 4096刚看了个自制框架的帖 ... -
TDD中,产品代码的接口是如何产生的?我的理解
2009-01-08 01:44 18462010年10月13日 再次补充 ...
相关推荐
测试驱动开发(Test-Driven Development,简称TDD)是一种软件开发方法,强调在编写实际功能代码之前,先编写测试用例。这种方法的核心理念是“先写测试,再写代码”。TDD通过引入测试来引导软件设计,使得开发过程...
### 使用PHPUnit进行TDD驱动开发 #### 一、引言 测试驱动开发(TDD, Test-Driven Development)是一种软件开发方法论,它要求在编写实际功能代码之前先编写测试用例。通过这种方式,可以确保代码的质量,并且有助...
这部分内容对于初学者非常友好,即使没有TDD经验也能轻松上手。 2. **嵌入式C语言特性**:深入讲解了C语言在嵌入式环境下的特性和限制,例如内存管理、中断处理等,并讨论了如何针对这些特性进行测试。 3. **单元...
### UMTS-TDD 手册知识点解析 #### 核心知识点概述 本文档主要针对的是**NS2网络仿真软件**中的**UMTS-TDD**(Universal Mobile Telecommunications System - Time Division Duplex)仿真方法进行了深入细致的介绍...
单元测试与TDD实践 **一、单元测试之测试目的** 单元测试,作为软件开发过程中的重要环节,其核心目标在于确保代码的质量、可维护性和可扩展性。它通过独立测试软件中的最小可测试单元,如函数或方法,来验证其...
《Test Driven: Practical TDD and Acceptance TDD for Java Developers》是一本专注于Java开发者进行测试驱动开发(TDD)和验收测试驱动开发(Acceptance TDD)的专业书籍。这本书以PDF英文版的形式提供,旨在帮助...
"GSM TDD 噪声分析" GSM TDD 噪声是一种常见的干扰现象,发生在 GSM 通信系统中的射频部分。这种噪声的产生是由于天线辐射出的射频能量和 PA 突发工作时带动电源的干扰。为了减少这种噪声的影响,我们可以采用一些...
【Laravel开发-TDD(测试驱动开发)】 在软件开发领域,TDD(Test-Driven Development,测试驱动开发)是一种编程实践,它强调先编写测试用例,再编写实现功能的代码。Laravel,作为一款流行的PHP框架,高度支持TDD...
**Ruby-TDD实战:Test Driven Development in Action** 在软件开发领域,Test-Driven Development(TDD)是一种编程实践,它强调先编写测试用例,然后编写满足这些测试的最小功能代码。Ruby作为一种动态、灵活的...
### 测试驱动开发 (TDD) 知识点解析 ...无论是对于初学者还是有一定经验的开发者来说,这都是一本非常有价值的参考书籍。TDD 不仅是一种开发方法,更是一种思考方式,它帮助我们构建高质量的软件产品。
本书可以作为移动端开发初学者入门TDD的好书。在阅读该书时,读者可以期望学习到如何在iOS应用开发中应用TDD的原则和实践,以及如何利用Swift语言的优势来构建稳健的软件。 文档信息还包含了版权信息,表明这本书是...
华为LTE TDD系统原理培训PPT文档
在C#编程环境中,测试驱动开发(Test-Driven Development,简称TDD)是一种软件开发方法论,它强调先编写测试用例,然后根据这些测试用例来实现功能代码。这种做法有助于确保代码的质量,减少错误,并提高开发效率。...
测试驱动开发(TDD)是一种软件开发方法,它要求开发者首先编写失败的单元测试用例,然后再编写足够的代码以使测试通过。接下来,开发者会对代码进行重构以改善设计,同时确保测试依然能够通过。这个过程循环进行,...
### TDD-CDMA在无线通信中的应用 #### 一、引言 TDD-CDMA(时分双工-码分多址)是无线通信技术中的一个重要分支,它结合了时分双工(TDD)与码分多址(CDMA)两种技术的特点,为移动通信系统提供了高效的数据传输解决...
测试驱动开发(Test-Driven Development,简称TDD)是一种软件开发方法,它的核心思想是“先写测试,再写代码”。TDD强调在编写实际功能代码之前,先编写能够失败的单元测试,确保测试覆盖了预期的功能需求。这种...
### TDD读书报告知识点梳理 #### 一、了解和认识TDD - **定义**: 测试驱动开发(Test-Driven Development, TDD)是一种软件开发方法论,它要求开发人员在编写功能代码前先编写测试代码,以确保功能代码的质量。 - ...