20155303 实验二 Java面向对象程序设计

20155303 实验二 Java面向对象程序设计

目录

• 一、单元测试和TDD

  任务一：实现百分制成绩转成“优、良、中、及格、不及格”五级制成绩的功能

  任务二：以TDD的方式研究学习StringBuffer

• 二、面向对象三要素：封装、继承、多态

  任务三：使用StarUML对实验二中的代码进行建模

• 三、设计模式

  任务四：对MyDoc类进行扩充，让其支持Long类，初步理解设计模式

• 附：练习

  任务五：以TDD的方式开发一个复数类Complex

• 四、实验过程中遇到的问题及解决：

  问题一：@Test或者import junit.framework.TestCase;是红色的怎么办？

  问题二：如何写好一个测试单元？怎样使用各种断言方法？

  问题三：如何解决这个“red bar”？

  问题四：Java中StringBuffer的capacity问题探究

• 五、实验体会与总结

• 六、参考资料

一、单元测试和TDD

用程序解决问题时，要学会写以下三种代码：

• 伪代码
• 产品代码
• 测试代码

正确的顺序应为：伪代码（思路）→ 测试代码（产品预期功能）→ 产品代码（实现预期功能），这种开发方法叫“测试驱动开发”（TDD）。TDD的一般步骤如下：

• 明确当前要完成的功能，记录成一个测试列表
• 快速完成编写针对此功能的测试用例
• 测试代码编译不通过（没产品代码呢）
• 编写产品代码
• 测试通过
• 对代码进行重构，并保证测试通过（重构下次实验练习）
• 循环完成所有功能的开发

基于TDD，可以有效避免过度开发的现象，因为我们只需要让测试通过即可。

任务一：实现百分制成绩转成“优、良、中、及格、不及格”五级制成绩的功能

以这个任务为例，我们来对TDD方法进行一次小小的实践。

首先要明白自己的程序需要进行哪些操作？要实现什么目标？伪代码可以帮我们理清思路。

百分制转五分制：
如果成绩小于60，转成“不及格”
如果成绩在60与70之间，转成“及格”
如果成绩在70与80之间，转成“中等”
如果成绩在80与90之间，转成“良好”
如果成绩在90与100之间，转成“优秀”
其他，转成“错误”

伪代码不需要说明具体调用的方法名，甚至不需要强调你打算使用的语言，理清思路即可。

其次，选择一种语言把伪代码实现，也就成了产品代码。

public class MyUtil{
    public static String percentage2fivegrade(int grade){
        //如果成绩小于0，转成“错误”
        if ((grade < 0))
            return "错误";
            //如果成绩小于60，转成“不及格”
        else if (grade < 60)
            return "不及格";
            //如果成绩在60与70之间，转成“及格”
        else if (grade < 70)
            return "及格";
            //如果成绩在70与80之间，转成“中等”
        else if (grade < 80)
            return "中等";
            //如果成绩在80与90之间，转成“良好”
        else if (grade < 90)
            return "良好";
            //如果成绩在90与100之间，转成“优秀”
        else if (grade <= 100)
            return "优秀";
            //如果成绩大于100，转成“错误”
        else
            return "错误";
    }
}

产品代码是为用户提供的，为了保证正确性，我们需要对自己的程序进行测试，考虑所有可能的情况，来判断结果是否合乎要求。这是我们就需要写测试代码。

根据我们现在的理解，测试代码不就是不断调用System.out.println()，来判断输出是否合乎预期嘛？所以可能会写成下面这种代码：

public class MyUtilTest {
    public static void main(String[] args) {
        if(MyUtil.percentage2fivegrade(55) != "不及格")
            System.out.println("test failed!");
        else if(MyUtil.percentage2fivegrade(65) != "及格")
            System.out.println("test failed!");
        else if(MyUtil.percentage2fivegrade(75) != "中等")
            System.out.println("test failed!");
        else if(MyUtil.percentage2fivegrade(85) != "良好")
            System.out.println("test failed!");
        else if(MyUtil.percentage2fivegrade(95) != "优秀")
            System.out.println("test failed!");
        else
            System.out.println("test passed!");
    }
}

如果输出test passed!，那就代表通过测试咯~

可是...如果输出test failed!呢？那事情就很糟糕了。我们需要把每一个测试用例的结果都打印出来，看看到底是哪里出现了该死的“test failed”。本题中的测试用例很少，那如果做大的项目时有成千上万个用例呢？

不用担心！Java中有单元测试工具JUnit来辅助进行TDD，我们用TDD的方式把前面百分制转五分制的例子重写一次，体会一下有测试工具支持的开发的好处。

鼠标放在需要测试的类上单击，出现一个黄色灯泡，点击选择“Create Test”，就可以新建一个测试类啦~

那么，我们可以这么写测试代码：

import org.junit.Test;
import junit.framework.TestCase; //注意导包！！！
public class MyUtilTest extends TestCase {
    @Test
    public void testNormal() {
        assertEquals("不及格", MyUtil.percentage2fivegrade(55));
        assertEquals("及格", MyUtil.percentage2fivegrade(65));
        assertEquals("中等", MyUtil.percentage2fivegrade(75));
        assertEquals("良好", MyUtil.percentage2fivegrade(85));
        assertEquals("优秀", MyUtil.percentage2fivegrade(95));
    }
}

如果出现问题，IDEA就会提示我们具体是哪一步出错了。比如下面这个实例（我把95分的断言值改成了“良好”，我们知道测试肯定不会通过）：

可以看出，IDEA提示我们Expected:良好； Actual:优秀，最后一行还有at test2.MyUtilTest.testNormal(MyUtilTest.java:11)，这下我们明白了，是testNormal()方法中一个为“良好”的断言错了。这样一来，是不是比上面那种方法方便很多了呢？

当然了，测试代码不能随便一写草草了事，作为开发者的我们必须要考虑得足够周全，尤其是各种边界情况以及非法输入等等。比如本题我们需要添加testExceptions()、testBoundary()等等各种方法进行测试。这些老师的教程里写得很详细，我在此就不赘述了。

任务二：以TDD的方式研究学习StringBuffer

这个任务主要锻炼我们自己写JUnit测试用例的能力。老师在教程里给出的程序如下：

public static void main(String [] args){
       StringBuffer buffer = new StringBuffer();
       buffer.append('S');
       buffer.append("tringBuffer");
       System.out.println(buffer.charAt(1));
       System.out.println(buffer.capacity());
       System.out.println(buffer.length());
       System.out.println(buffer.indexOf("tring"));
       System.out.println("buffer = " + buffer.toString());

首先我们需要对这个程序进行改写，写成上面的产品代码那种类型的，以便于我们进行测试。

对于这个程序，我们先来看一看哪些方法需要测试？有四个，charAt()、capacity()、length()、indexOf。在产品代码里，我们需要为这四个方法加上返回值，并与我们的断言进行比较。产品代码如下：

public class StringBufferDemo{
   StringBuffer buffer = new StringBuffer();
   public StringBufferDemo(StringBuffer buffer){
       this.buffer = buffer;
   }
   public Character charAt(int i){
       return buffer.charAt(i);
   }
   public int capacity(){
       return buffer.capacity();
   }
   public int length(){
       return buffer.length();
   }
   public int indexOf(String buf) {
       return buffer.indexOf(buf);
   }
}

接下来我们需要对调用各种方法的返回值进行猜测。查询API文档可知，对charAt(int i)的解释为：“返回此序列中指定索引处的 char 值。第一个 char 值在索引 0 处，第二个在索引 1 处，依此类推，这类似于数组索引。”indexOf(String s)则返回输入的子字符串的第一个字母在母字符串的位置。这两个看起来都比较好理解，那capacity()和length()呢？我在学习StringBuffer的时候也遇到了这样的困惑，对于这两者之间的区别问题，可以参考我博客的“问题解决”模块。

基于以上的思考和学习，我们可以对各个方法的返回值有一个精确地分析，接下来只需要比较产品代码中的方法与我们的断言值是否相等即可。

出于对老师这篇博客中问题的思考，我设置了长度不同的三个字符串进行测试，代码如下：

public class StringBufferDemoTest extends TestCase {
    StringBuffer a = new StringBuffer("StringBuffer");//测试12个字符（<=16）
    StringBuffer b = new StringBuffer("StringBufferStringBuffer");//测试24个字符（>16&&<=34）
    StringBuffer c = new StringBuffer("StringBufferStringBufferStringBuffer");//测试36个字符（>=34）
    @Test
    public void testcharAt() throws Exception{
        assertEquals('S',a.charAt(0));
        assertEquals('g',a.charAt(5));
        assertEquals('r',a.charAt(11));
    }
    @Test
    public void testcapacity() throws Exception{
        assertEquals(28,a.capacity());
        assertEquals(40,b.capacity());
        assertEquals(52,c.capacity());
    }
    @Test
    public void testlength() throws Exception{
        assertEquals(12,a.length());
        assertEquals(24,b.length());
        assertEquals(36,c.length());
    }
    @Test
    public void testindexOf() throws Exception{
        assertEquals(0,a.indexOf("Str"));
        assertEquals(5,a.indexOf("gBu"));
        assertEquals(10,a.indexOf("er"));
    }
}

可以看到，出现了“green bar”，说明测试通过了，我们对StringBuffer也有了更加深刻的认识。

返回目录

二、面向对象三要素：封装、继承、多态

面向对象(Object-Oriented)的三要素包括：封装、继承、多态。面向对象的思想涉及到软件开发的各个方面，如面向对象分析（OOA）、面向对象设计（OOD）、面向对象编程实现(OOP)。OOA根据抽象关键的问题域来分解系统，关注是什么（what）。OOD是一种提供符号设计系统的面向对象的实现过程，用非常接近问题域术语的方法把系统构造成“现实世界”的对象，关注怎么做（how）,通过模型来实现功能规范。OOP则在设计的基础上用编程语言（如Java）编码。贯穿OOA、OOD和OOP的主线正是抽象。

任务三：使用StarUML对实验二中的代码进行建模

UML是一种通用的建模语言，可以非常直观地表现出各个结构之间的关系。

基于以上学习，我们在UML中实现了类，继承和接口的组合：

当然，UML还可以实现更多更复杂的功能，以上只是一个小小的实践。

返回目录

三、设计模式

面向对象三要素是“封装、继承、多态”，任何面向对象编程语言都会在语法上支持这三要素。如何借助抽象思维用好三要素特别是多态还是非常困难的，S.O.L.I.D类设计原则是一个很好的指导：

• SRP(Single Responsibility Principle,单一职责原则)
• OCP(Open-Closed Principle,开放-封闭原则)
• LSP(Liskov Substitusion Principle,Liskov替换原则)
• ISP(Interface Segregation Principle,接口分离原则)
• DIP(Dependency Inversion Principle,依赖倒置原则)

下面，我们通过具体的题目来学习设计模式。

任务四：对MyDoc类进行扩充，让其支持Long类，初步理解设计模式

OCP是OOD中最重要的一个原则，要求软件实体（类，模块，函数等）应该对扩充开放，对修改封闭。也就是说，软件模块的行为必须是可以扩充的，在应用需求改变或需要满足新的应用需求时，我们要让模块以不同的方式工作；同时，模块的源代码是不可改动的，任何人都不许修改已有模块的源代码。OCP可以用以下手段实现：（1）抽象和继承，（2）面向接口编程。

以这道题为例，已有的支持Int型的代码如下：

abstract class Data{
    public abstract void DisplayValue();
}
class Integer extends Data {
  int value;
   Integer(){
      value=100;
   }
   public void DisplayValue(){
       System.out.println(value);
   }
}
class Document {
     Data pd;
     Document() {
        pd=new Integer();
     }
     public void DisplayData(){
        pd.DisplayValue();
     }
}
public class MyDoc {
    static Document d;
    public static void main(String[] args) {
        d = new Document();
        d.DisplayData();
    }
}

如果要求支持Long类，Document类要修改构造方法，这还违反了OCP原则。封装、继承、多态解决不了问题了，这时需要设计模式了：

abstract class Data {
    abstract public void DisplayValue();
}
class Integer extends  Data {
    int value;
    Integer() {
         value=100;
    }
    public void DisplayValue(){
        System.out.println (value);
    }
 }
// Pattern Classes
abstract class Factory {
   abstract public Data CreateDataObject();
}
class IntFactory extends Factory {
   public Data CreateDataObject(){
     return new Integer();
   }
}

这样一来，我们只需要class Long extends Data、class LongFactory extends Factory即可使系统支持Long类型，测试代码如下：

public class MyDoc {
    static Document d;
    public static void main(String[] args) {
        d = new Document(new LongFactory());
        d.DisplayData();
    }
}

我们看到，通过增加了一层抽象层使代码符合了OCP原则，使代码有良好的可扩充性、可维护性。不过，设计模式也不能过度使用，具体在哪些场合应用还要看实际问题。

返回目录

附：练习

任务五：以TDD的方式开发一个复数类Complex

经过以上的学习，我们已经可以基本熟练地应用TDD方法，并跟随TDD方法的节奏设计出伪代码、产品代码和测试代码了，这个任务算是对以上学习内容的回顾。

TDD的编码节奏是：

• 增加测试代码，JUnit出现红条
• 修改产品代码
• JUnit出现绿条，任务完成

首先，我们来写伪代码：

（1）属性：复数包含实部和虚部两个部分，
double RealPart;复数的实部
double ImagePart;复数的虚部
getRealPart():返回复数的实部
getImagePart();返回复数的虚部
setRealPart():设置复数的实部
setImagePart();设置复数的虚部
输出形式：a+bi
（2）方法：
①定义构造函数
public Complex()
public Complex(double R,double I)
②定义公有方法:加减乘除
Complex ComplexAdd(Complex a):实现复数加法
Complex ComplexSub(Complex a):实现复数减法
Complex ComplexMulti(Complex a):实现复数乘法
Complex ComplexDiv(Complex a):实现复数除法
③Override Object
public String toString():将计算结果转化为字符串形式并输出

在测试代码中，我们需要对以上提到的方法进行测试。写测试代码时，如果调用了不存在的方法，可以点击这个方法旁边的小灯泡进行修复，这个操作会对应的产品代码中增加一个方法，我们只需要描述这个方法的操作即可，非常方便。

public class ComplexTest extends TestCase {
    Complex c1 = new Complex(0, 3);
    Complex c2 = new Complex(-1, -1);
    Complex c3 = new Complex(2,1);
    @Test
    public void testgetRealPart() throws Exception {
        assertEquals(-1.0, Complex.getRealPart(-1.0));
        assertEquals(5.0, Complex.getRealPart(5.0));
        assertEquals(0.0, Complex.getRealPart(0.0));
    }
    @Test
    public void testgetImagePart() throws Exception {
        assertEquals(-1.0, Complex.getImagePart(-1.0));
        assertEquals(5.0, Complex.getImagePart(5.0));
        assertEquals(0.0, Complex.getImagePart(0.0));
    }
    @Test
    public void testComplexAdd() throws Exception {
        assertEquals("-1.0+2.0i", c1.ComplexAdd(c2).toString());
        assertEquals("2.0+4.0i", c1.ComplexAdd(c3).toString());
        assertEquals("1.0", c2.ComplexAdd(c3).toString());
    }
    @Test
    public void testComplexSub() throws Exception {
        assertEquals("1.0+4.0i", c1.ComplexSub(c2).toString());
        assertEquals("-2.0+2.0i", c1.ComplexSub(c3).toString());
        assertEquals("-3.0 -2.0i", c2.ComplexSub(c3).toString());
    }
    @Test
    public void testComplexMulti() throws Exception {
        assertEquals("3.0 -3.0i", c1.ComplexMulti(c2).toString());
        assertEquals("-3.0+6.0i", c1.ComplexMulti(c3).toString());
        assertEquals("-1.0 -3.0i", c2.ComplexMulti(c3).toString());
    }
    @Test
    public void testComplexComplexDiv() throws Exception {
        assertEquals("-1.5 -1.5i", c1.ComplexDiv(c2).toString());
        assertEquals("1.2+0.6i", c1.ComplexDiv(c3).toString());
        assertEquals("-0.6 -0.6i", c2.ComplexDiv(c3).toString());
    }
}

通过不断修复，产品代码也写好了，测试一下能不能出现“green bar”，如果测试不通过再根据提示修改产品代码。

产品代码如下：

public class Complex{
    private double r;
    private double i;

    public Complex(double r, double i) {
        this.r = r;
        this.i = i;
    }

    public static double getRealPart(double r) {
        return r;
    }

    public static double getImagePart(double i) {
        return i;
    }

    public Complex ComplexAdd(Complex c) {
        return new Complex(r + c.r, i + c.i);
    }
    public Complex ComplexSub(Complex c) {
        return new Complex(r - c.r, i - c.i);
    }
    public Complex ComplexMulti(Complex c) {
        return new Complex(r * c.r - i * c.i, r * c.i + i * c.r);
    }
    public Complex ComplexDiv(Complex c) {
        return new Complex((r * c.i + i * c.r)/(c.i * c.i + c.r * c.r), (i * c.i + r * c.r)/(c.i * c.i + c.r * c.r));
    }

    public String toString() {
        String s = " ";
        if (i > 0)
            s =  r + "+" + i + "i";
        if (i == 0)
            s =  r + "";
        if (i < 0)
            s = r + " " + i + "i";
        return s;
    }
}

返回目录

四、实验过程中遇到的问题及解决

问题一：@Test或者import junit.framework.TestCase;是红色的怎么办？

我和大多数同学一样都遇到了这种情况，是因为没有导入相应的包。参考老师的教程并查阅了相关资料解决了这个问题。

解决方法如下：

首先，进入页面左上角File→Project Structure...：

进入之后，根据你的IDEA安装地址导入这两个包就可以了。

问题二：如何写好一个测试单元？怎样使用各种断言方法？

本次实验我们着重学习了如何使用Junit进行单元测试，深入思考一下：单元测试中需要考虑哪些情况呢？

博客单元测试应该测试什么？——Right-BICEP对这个问题进行了较为详细的分析，大致可以总结为：

• 结果是否正确

  这是最基本的，就是看程序运行之后的结构和文档是否一致。

• 边界条件

  • 一致性(Conformance)——值是否符合预期的格式？
  • 有序性(Ordering)——一组值是该有序的，还是该无序的？
  • 区间性(Range)——值是否在一个合理的最大值和最小值的范围之内？
  • 引用、耦合性(Reference)——代码是否引用了一些不受代码本身直接控制的外部因素？
  • 完全伪造或者不一致的输入数据、格式错误的数据、空值或者不完整的值，如0， 0.0， “”， null之类的等等。

• ...

在本次实验的单元测试中，我们大量使用了assertEquals()方法，来判断测试值是否与期望值相等。assertEquals()是应用非常广泛的一个断言，它的作用是比较实际的值和用户预期的值是否一样。

通过学习了解到，还可以使用assertThat(actual, matcher)方法，查看实际值是否满足指定的条件。assertThat(actual, matcher)方法可以实现一般匹配、字符串匹配、数值匹配、collection匹配等等，非常实用。

以下面这个程序为例，我随意写了几个方法，打算使用assertThat(actual, matcher)方法进行测试：

import java.util.List;
import java.util.ArrayList;
public class AssertDemo {
    public int add(int a, int b) {
        return a + b;
    }

    public String getName(String name) {
        return name;
    }

    public List<String> getList(String item) {
        List<String> l = new ArrayList<>();
        l.add(item);
        return l;
    }
}

JUnit4.4引入了Hamcrest框架，Hamcest提供了一套匹配符Matcher，这些匹配符更接近自然语言，可读性高，更加灵活。不过需要注意的是，使用assertThat(actual, matcher)方法必须导入相应的类或方法：

import static org.junit.Assert.*;
import static org.hamcrest.CoreMatchers.*;
import static org.junit.matchers.JUnitMatchers.*;

得到测试代码如下：

public class AssertDemoTest {
    @Test
    public void testAdd() {

        //一般匹配符
        int s = new AssertDemo().add(1, 1);
        //anything：无论什么条件，测试都通过
        assertThat(s, anything());
        //is：变量的值等于指定值时，测试通过
        assertThat(s, is(2));
        //not：和is相反，变量的值不等于指定值时，测试通过
        assertThat(s, not(1));
    }
    @Test
    public void testgetName() {
        //字符串匹配符
        String n = new AssertDemo().getName("Magical");
        //containsString：字符串变量中包含指定字符串时，测试通过
        assertThat(n, containsString("ci"));
        //startsWith：字符串变量以指定字符串开头时，测试通过
        assertThat(n, startsWith("Ma"));
        //endsWith：字符串变量以指定字符串结尾时，测试通过
        assertThat(n, endsWith("l"));
        //euqalTo：字符串变量等于指定字符串时，测试通过
        assertThat(n, equalTo("Magical"));
    }
    @Test
     public void testgetList(){
        //集合匹配符
        List<String> l = new AssertDemo().getList("Magical");
        //hasItem：Iterable变量中含有指定元素时，测试通过
        assertThat(l, hasItem("Magical"));

    }
}

JUnit框架Assert类中还有很多断言方法，比如assertTrue与assertFalse断言、assertNull与assertNotNull断言、assertSame与assertNotSame断言、fail断言等等，还有待我们进一步学习总结。

问题三：如何解决这个“red bar”？

在实验过程中遇到了这样的问题：

在测试类中定义了c1、c2和c3：

Complex c1 = new Complex(0, 3);
Complex c2 = new Complex(-1, -1);
Complex c3 = new Complex(2,1);

并测试复数的减法：

public void testComplexSub() throws Exception {
        assertEquals("1.0+4.0i", c1.ComplexSub(c2).toString());
        assertEquals("-2.0+2.0i", c1.ComplexSub(c3).toString());
        assertEquals("-3.0 -2.0i", c2.ComplexSub(c3).toString());
    }

但是测试的时候却出现了“red bar”：

检查产品代码中复数的减法也没有问题：

public Complex ComplexSub(Complex c) {
        return new Complex(r - c.r, i - c.i);
    }

那错误在哪里呢？

观察错误提示，断言值为-3.0 -2.0i但实际输出值为-5.0i，-5.0恰巧是-3.0 -2.0i实部和虚部的和。好像有点思路了...返回去看产品代码中的toString()方法，注意到当虚部小于零时，我直接进行了s = r + i + "i";操作，而在Java中，这个式子的含义是：先计算r + i的值，再转化为字符串形式，所以会得到错误的输出。将代码改为：s = r + " " + i + "i"，先进行强制类型转换，就解决了这个问题。

问题四：Java中StringBuffer的capacity问题探究

在研究学习StringBuffer的过程中，对capacity()有疑惑，查询了API文档了解到：

从API查到capacity的作用是查看StringBuffer的容器容量是多少，刚开始纳闷这个跟length的区别在哪？

于是自己写了一个程序进行测试分析：

public class capacityDemo {
    public static void main(String[] args) {
        StringBuffer b = new StringBuffer();//初始分配空间为0+16
        for(int i = 0; i < 50; i++){
            b = b.append("A");
            System.out.println(b);
            System.out.print("length()="+b.length());
            System.out.println("capacity()="+b.capacity());
        }
    }
}

打印运行结果：

可以看到，对于空字符串，调用capacity()方法初始分配值为16；大小超过16时则扩充容量为34，再次扩充得到70。

那么问题来了！16、34、70是怎么得到的呢？试验了几次还是有点不解。所以直接跟进源码分析。

直接通过new StringBuffer(String str)；时，capacity是str.length+16，从源码可知：

如果小于16则默认容器的大小为16。如果大于16则会调用expandCapacity 函数进行容量的扩展，扩展方式如下：

由源码可以看到扩展的规则是把旧的容量（value的长度）*2+2，然后与现有的比较，如果小于则把现有的容量当做新的，如果大于则用新得到的容量。

所以第一次append时，小于16则不需扩展，如果大于16则会直接扩展到34（16*2+2），比较得到大于append后的长度的话则用34，如果不 是则用append后的长度。

此时capacity的大小等于append后的长度，如果在append的话，若不超过70（34*2+2）的话，此时则capacity为70，如果超过70则继续用第二次append后的总长度。

这样一来，对capacity()的理解就比较透彻了。

返回目录

五、实验体会与总结

这周的实验内容非常丰富，主要学习了如何编写测试代码。

在开发软件的过程中，用户需要实际运行所编写的代码以确保程序的正确性。当软件变得越来越大，再去添加新的功能或做一些新的改动时，就很容易带来新的问题，甚至会使程序无法正常运行。然而要手动的运行代码，测试代码的可行性也是非常枯燥以及非常耗费时间的事情。

为了减少这种手动测试，可以通过创建单元测试来自动完成测试的工作。当修改代码或者添加新功能后，可以执行单元测试来保证代码运行无误。所有测试工作都是由单元测试自动完成的，开发人员所要做的就是看看程序的执行状态。

使用单元测试的另一个理由是实现测试驱动的开发。测试驱动的开发尝试首先写出单元测试，然后完成实际的代码。通过单元测试来提供类的定义，当实际开始编写代码时，用户仅仅需要做的就是具体类的实现，只要单元测试运行通过，代码的实现也将告一段落了。写单元测试的同时，也在同时在做项目的设计，当项目结束后，单元测试还将是不错的文档，何乐而不为呢？

在Java语言中，可以通过JUnit框架进行单元测试。单元测试的实现是很简单的，可以认为它只是判断在某一个时刻，程序运行的值和预期的值是否一致，但在实际的应用的时候是很灵活的，在此介绍JUnit中的一些断言以及JUnit测试框架的使用，使读者能够快速的进入单元测试的领域，更快的进行开发。

JUnit提供了一些辅助函数，用于帮助开发人员确定某些被测试函数是否工作正常。通常而言，把所有这些函数统称为断言，断言是单元测试最基本的组成部分。

除此之外，本次实验还学习了TDD方式、UML建模、S.O.L.I.D原则以及设计模式等等，既加深了对之前内容的理解，又规范了我们的编程流程，对思维也是一个很好的梳理，希望能把这些知识在今后的学习实践中广泛应用。

步骤	耗时	百分比
需求分析	12min	10%
设计	10min	8%
代码实现	48min	40%
测试	40min	34%
分析总结	10min	8%

返回目录

六、参考资料

• 实验二 Java面向对象程序设计
• Intellj IDEA 简易教程
• 积极主动敲代码，使用JUnit学习Java
• UML基础教程
• 单元测试应该测试什么？——Right-BICEP
• junit 测试中各种断言用法
• Junit使用教程（二）
• java单元测试(Junit)
• 菜鸟学Java（二十一）——如何更好的进行单元测试——JUnit
• 关于Java中StringBuffer的capacity问题

返回目录