测试驱动开发(TDD)

测试驱动开发的基本概念

  • 为什么会出现测试驱动开发
    • 当有一个新的任务时,往往第一个念头就是如何去实现它呢?
    • 拿到任务就开始编码,一边写,变修改和设计
    • 我已经调试了好几遍,应该不会有问题了,好了,先休息一下吧
    • 测试是QA的事,我为什么要做啊,我做了,他们做什么?
    • 奇怪了,怎么代码跟开发文档有这么大的区别啊?
    • 开发部在搞什么啊,怎么代码有这么多的BUG?
    • 这段代码想干嘛?
    • ……
  • 什么是测试驱动
    • 测试驱动是一种开发形式:
      • 首先要编写测试代码
      • 除非存在相关测试,否则不编写任何的产品代码
      • 由测试来决定需要写什么样的代码
      • 要求维护一套详细的测试集
  • 目标
    • 代码整洁可用
      • 只有测试失败时,我们才写代码
      • 消除重复设计,优化设计结构

测试驱动开发的流程

1097578-20170904112719897-904978326.png

Test-Driven Design(TDD)

是一种开发风格,它要求程序员做到:

  • 在写产品代码之前,先写它的单元测试(Unit Tests)
  • 没有单元测试的Class不运行作为产品代码
  • 单元测试用例决定了如何写产品代码
  • 不断地成功运行所有的单元测试用例
  • 不断地完善单元测试用例

Test-Driven Design是把需求分析,设计,质量控制量化的过程!

如何做Test-Driven Design and Development

在开发一个新功能之前:

  • 首先确定“做什么”(不是要如何做!)
    • 例如,一个网站的增加用户的功能,我们需要一个方法来增加一个用户:
      • public void addUser(User user)
      • 功能包括:增加一个用户(在数据库中插入一条记录);如果已经有相同的用户,应该返回一个用户已存在的消息
  • 然后为这个功能写单元测试例子(Unit Test)
    • 单元测试用例要覆盖这个Method的“做什么”
    • 所以我们至少要有两个测试用例:
      • Test Case1:测试成功增加一个用户
      • Test Case 2:测试增加一个已存在的用户
      • 其它边缘情况测试:Test Case 3:传入的User对象为NULL
  • 写生成(Production)代码
    • 我们清楚地知道这段代码需要做什么,清晰的表明这段代码的Contracts。
    • 只需要能实现在Unit Test中的Contracts和能够通过它的Unit Test
  • 运行Unit Test
    • 如果顺利通过,你已经很好的完成了你的任务
    • 如果没通过,修补代码直到能通过Unit Test为止
    • 如果出现在Unit Test中没预先设定的结果,在Unit Test中增加一个Test Case,修补代码直到通过所有的Test Case为止。

TDD 和 PSP

Personal Software Process的development
1097578-20170904112355585-1575936049.png

Test-Driven Design and Development
1097578-20170904112927663-1438038544.png

什么时候写Tests?

  • 如果你要写一个新的功能,请先写它的测试用例
  • 如果你要在没有经过测试的代码上写新的功能,请先写目前代码的测试用例
  • 如果你要Fix一个Bug,请先为这个Bug写一个测试用例
  • 如果你要Refactor没有测试过的代码,请先写一个测试用例
  • 如果发现一个边缘例外值,请为它写一个测试用例

xUnit 工具

  • Java Class的测试Framework: JUnit
  • Java Swing app 的测试Framework: JFCUnit
  • Java Server Side(EJB,Servlet)的测试Framework:Catus
  • HTML Page的测试Framework: HTMLUnit、HTTPUnit
  • C++的测试Framework: CPPUnit
  • .Net APP的测试Framework: .NetUnit

实例

考虑一个质因数分解的例子:将任何一个大于1的自然数分解成质因子相乘,如4=2*2,24=2*2*2*3等。

第一天

  1. 建立Maven工程
    1097578-20170904090546601-1016981919.png
    1097578-20170904090727788-1399759757.png
    1097578-20170904090856257-1553051450.png
    创建如下Maven工程:
    1097578-20170904091454976-2033912277.png
    在pom.xml文件中加入JUnit信息:
    1097578-20170904091725257-607372060.png
  2. 根据测试驱动要求,写一个TestCase:
    1097578-20170904092936522-1796455594.png
    1097578-20170904093020257-1535902742.png

写第一个TestCase:
public class FactorTest { @Test public void testFactor() { assertEquals(2, Factor.factor(2)); } }
创建一个类Factor和静态方法factor:

public class Factor {
    public static int factor(int i){
        return 2;
    }
}

运行第一个TestCase:
1097578-20170904094856210-1847692582.png
测试通过:
1097578-20170904095012382-161665521.png
于是形成质因数分解的第一个版本。

第二天

第一个测试用例可以测试2,那么3呢?
新增加一个测试用例:

public class FactorTest {
    
    @Test
    public void testFactor() {
        assertEquals(2, Factor.factor(2));
        assertEquals(3, Factor.factor(3));
    }

}

根据测试用例,修改Factor类的代码以通过测试用例:

public class Factor {
    public static int factor(int i){
        if(i==2) return 2;
        if(i==3) return 3;
        return 0;
    }
}

运行测试用例:
1097578-20170904095825210-702624204.png
测试通过!

第三天

在前2个测试用例的基础上,增加4,又会怎样呢?
1097578-20170904100125304-802946209.png
发现测试4,不能通过?怎么办?开始修改Factor类的代码!
首先希望测试4时,返回的是质因子的集合,修改测试用例:

assertEquals(Arrays.asList(2,2), Factor.factor(4));

对应的,其它测试用例相应发生更改:

public class FactorTest {
    
    @Test
    public void testFactor() {
        assertEquals(Arrays.asList(2), Factor.factor(2));
        assertEquals(Arrays.asList(3), Factor.factor(3));
        assertEquals(Arrays.asList(2,2), Factor.factor(4));
    }
}

由于返回的是数组集合,因此修改Factor类的factor方法:

public class Factor {
    public static List<Integer> factor(int i){
        List<Integer> l=new ArrayList<Integer>();
        if(i==2) l.add(2);
        if(i==3) l.add(3);
        return l;
    }
}

跑测试,发现测试不通过,据此修改factor方法,以使得4的测试能够通过:

public class Factor {
    public static List<Integer> factor(int i){
        List<Integer> l=new ArrayList<Integer>();
        if(i==2) l.add(2);
        if(i==3) l.add(3);
        if(i==4){
            l.add(2);
            l.add(2);
        }
        return l;
    }
}

运行JUnit Test:
1097578-20170904101205194-1874608432.png
发现测试通过,OK!

第四天

那么5呢?能测试通过吗?
1097578-20170904101410710-1058841186.png
不行!修改Factor类的factor方法:

public class Factor {
    public static List<Integer> factor(int i){
        List<Integer> l=new ArrayList<Integer>();
        if(i==2) l.add(2);
        if(i==3) l.add(3);
        if(i==4){
            l.add(2);
            l.add(2);
        }
        if(i==5) l.add(5);
        return l;
    }
}

测试通过:
1097578-20170904101558944-704790434.png
如果再继续这么写下去,你会发现你的代码臃肿不堪,不忍直视!
那么这时候,我们需要对代码进行重构优化

当你无节操的修改代码以通过测试时,我们一定要在某个点停下来看看,我们是不是可以再优化些什么?
测试驱动容易让人进入一个局部关注点,不太关注思维的系统整体点。

停下脚步,回头看看我们的Factor类的factor方法,发现 i=2,i=3,i=5要做的事情似乎一样。
第一步,可以考虑将代码改成:

public class Factor {
    public static List<Integer> factor(int i){
        List<Integer> l=new ArrayList<Integer>();
        l.add(i);       
        if(i==4){
            l.add(2);
            l.add(2);
                        return l;
        }       
        return l;
    }
}

运行测试:
1097578-20170904103040476-382707095.png
发现4不能通过!发现4不能直接加。
怎么办?调整代码顺序!

public class Factor {
    public static List<Integer> factor(int i){
        List<Integer> l=new ArrayList<Integer>();               
        if(i==4){
            l.add(2);
            l.add(2);
            return l;
        }
        l.add(i);
        return l;
    }
}

运行JUnit Test:
1097578-20170904103401351-416912182.png
测试通过!与未重构前的代码相比,看上去漂亮多了!

第五天

接下来,我们测试6:

public class FactorTest {
    
    @Test
    public void testFactor() {
        assertEquals(Arrays.asList(2), Factor.factor(2));
        assertEquals(Arrays.asList(3), Factor.factor(3));
        assertEquals(Arrays.asList(2,2), Factor.factor(4));
        assertEquals(Arrays.asList(5), Factor.factor(5));
        assertEquals(Arrays.asList(2,3), Factor.factor(6));
    }
}

显然,6不能通过!因此修改Factor类的factor方法:

public class Factor {
    public static List<Integer> factor(int i){
        List<Integer> l=new ArrayList<Integer>();               
        if(i==4){
            l.add(2);
            l.add(2);
            return l;
        }
        if(i==6){
            l.add(2);
            l.add(3);
            return l;
        }
        l.add(i);
        return l;
    }
}

测试通过!
回头再看,i=4i=6的代码,发现有一个拆解的过程,都有一个共同的因子:2
因此,考虑对代码进行优化:

public class Factor {
    public static List<Integer> factor(int i){
        List<Integer> l=new ArrayList<Integer>();
        if(i%2==0){
            l.add(2);
            i=i/2;
        }       
        l.add(i);
        return l;
    }
}

运行测试:
1097578-20170904104247663-669611826.png
发现2不能通过,继续修改代码,排除2的情况:

public class Factor {
    public static List<Integer> factor(int i){
        List<Integer> l=new ArrayList<Integer>();
        if(i%2==0 && i>2){
            l.add(2);
            i=i/2;
        }       
        l.add(i);
        return l;
    }
}

测试通过
1097578-20170904104451226-2069009435.png

第六天

在此基础上,我们测试8:

assertEquals(Arrays.asList(2,2,2), Factor.factor(8));

发现测试不能通过!
发现8包含多个2,在Factor类的factor方法中,似乎应该将if语句改成while循环:

public class Factor {
    public static List<Integer> factor(int i){
        List<Integer> l=new ArrayList<Integer>();
        while(i%2==0 && i>2){
            l.add(2);
            i=i/2;
        }       
        l.add(i);
        return l;
    }
}

测试通过!
1097578-20170904105414429-819380098.png

第七天

测试9:

assertEquals(Arrays.asList(3,3), Factor.factor(9));

测试不通过!

public class Factor {
    public static List<Integer> factor(int i){
        List<Integer> l=new ArrayList<Integer>();
        while(i%2==0 && i>2){
            l.add(2);
            i=i/2;
        }
        while(i%3==0 && i>3){
            l.add(3);
            i=i/3;
        }
        l.add(i);
        return l;
    }
}

测试通过!
分别再对9,10,11,12,20进行测试:

assertEquals(Arrays.asList(3,3), Factor.factor(9));
assertEquals(Arrays.asList(2,5), Factor.factor(10));
assertEquals(Arrays.asList(11), Factor.factor(11));
assertEquals(Arrays.asList(2,2,3), Factor.factor(12));
assertEquals(Arrays.asList(2,2,5), Factor.factor(20));

测试通过:
1097578-20170904110210741-544513176.png

第八天

测试25:

assertEquals(Arrays.asList(5,5), Factor.factor(25));

测试不能通过!原因很简单,代码里面没有对因子5再做处理!
最直观地:

public class Factor {
    public static List<Integer> factor(int i){
        List<Integer> l=new ArrayList<Integer>();
        while(i%2==0 && i>2){
            l.add(2);
            i=i/2;
        }
        while(i%3==0 && i>3){
            l.add(3);
            i=i/3;
        }
        while(i%5==0 && i>5){
            l.add(5);
            i=i/5;
        }
        l.add(i);
        return l;
    }
}

测试通过!
这时候,我们需要停下脚步,优化代码,消除重复。
在TestCase的保护下,考虑对代码进行修改:

public class Factor {
    public static List<Integer> factor(int i){
        List<Integer> l=new ArrayList<Integer>();
        int k=2;
        while(k<i){
            while(i%k==0 && i>k){
                l.add(k);
                i=i/k;
            }
            k++;
        }       
        l.add(i);
        return l;
    }
}

测试通过!
考虑一个复杂的TestCase:

assertEquals(Arrays.asList(2,2,2,3,5,7,7,11), Factor.factor(2*2*2*3*5*7*7*11));

测试通过!
1097578-20170904111213101-600726317.png
回头看看这段代码是否可接受?

小结

测试驱动开发:

  • 能够保证编写单元测试
  • 使程序员坚持编写测试
  • 有助于澄清接口和行为的细节
  • 可证明、可再现、自动的验证
  • 增强改变事物的信心

转载于:https://www.cnblogs.com/happyzm/p/7468975.html

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值