必赢亚洲手机app下载


付出环境

System Center 2012 configuration manager and endpoint protection sp1 安装必赢亚洲手机app

code阅读笔记之八

单元测试


注:正文中的引用是直接引用作者来说,两条横线中间的段子的是自我要好的看法,其他大约都可以算是笔记了。


对于许两个人来说,所谓「单元测试」只是在大家忙碌地写完部分类如故措施——甚至一个工程——后,写下的部分「专用代码」来测试它们,而且这个代码往往都是一些简约的驱动程序来扶助大家和我们刚写好的次序开展交互。比如一些人写的单元测试会是那样的,单元测试跑起来后会监听键盘,然后我们键入某一个假名或者直接点击回车来推行某种测试步骤。

乘机「敏捷开发」和「测试驱动开发」的流行,渐渐地人们开首转移写单元测试的主意,现在的过多少人会把单元测试当做系统健康运行的管教——首先这多少个单元测试要保管覆盖了程序的每一个角落,然后每一趟这一个单元测试通过,就象征大家的先后完全没有问题了。

但是随着越来越多的人归心似箭把单元测试作为专业而去实践它,许多开发者忽略了一些非常微妙不过这多少个根本的点,而这一个点才是你写出优雅的测试的基本点元素。

测试驱动开发的3大定律

在做软件开发的时候:

  1. 在编辑正式代码此前,必须写出其相对应的单元测试;
    这就是说肯定要先写出一个单元测试(因为还并未编制正式代码,所以它必将会失败),再编辑正式代码。
  2. 只要一个单元测试退步了,就无须再编辑任何更多的单元测试了;
    而是要去编写相应的的可以使之通过的难为代码,编译失利也算;
  3. 假使正式代码可以使单元测试通过,就绝不再编辑更多的专业代码了;
    正规代码需要满意的绝无仅有目的就是通过单元测试,只要透过单元测试,就象征大家此部分的代码已经写完了。

详见解读能够参考鲍伯二伯的博客

保障单元测试的净化

多少人坚信「有总比没有强」,他们并不曾像对待专业代码这样对待测试代码,对测试代码的要求就是「快」,往往写出来的代码却特别猥琐。比如变量并不曾被突出得命名,测试代码中的方法又冗长又难懂,他们坚信测试代码不需要花那么多心境去设计,只要它们能做事就足足好了。

但是,质量差的测试代码等同于没有测试(或者甚至比一直不测试还要不佳)。因为我们的测试代码往往需要随着正式代码的变更而变化,如若你的测试代码写的很烂,那么您未来快要花更多的流年来修改它们,渐渐的那么些写得很烂的测试代码将会成为致命的负责。逐步的越来越多的人初叶抱怨测试代码成拖累了开发进度,进而最后废弃这么些测试。

敲定就是:测试代码和标准代码同样首要,我们应该像对待专业代码这样对待测试代码。

测试可以带动各样利益

如前方几章中提到的,有了覆盖所有正规代码的单元测试,你就足以放心大胆地对系统举行改动。这就会带动很多便宜:世故、可维护性和可重用性
而其貌不扬的测试代码会让你的代码丧失这么些利益。

什么样是整洁的单元测试

好的测试有3个要素:可读性、可读性、可读性

此地有一个FitNesse中的单元测试的例子,如代码8-1中所示的单元测试,其中带有了大气的底细实现,可读性极差,读者想要读懂这多少个测试是为什么的时候就会发现自己被淹没在了无止境的细节中。

//代码8-1
public void testGetPageHieratchyAsXml() throws Exception{
    crawler.addPage(root, PathParser.parse("PageOne"));
    crawler.addPage(root, PathParser.parse("PageOne.ChildOne"));
    crawler.addPage(root, PathParser.parse("PageTwo"));

    request.setResource("root");
    request.addInput("type", "pages");
    Responder responder = new SerializedPageResponder();
    SimpleResponse response =
        (SimpleResponse) responder.makeResponse(
            new FitNesseContext(root), request);
    String xml = response.getContent();

    assertEquals("text/xml", response.getContentType());
    assertSubString("<name>PageOne</name>", xml);
    assertSubString("<name>PageTwo</name>", xml);
    assertSubString("<name>ChildOne</name>", xml);
}

public void testGetPageHieratchyAsXmlDoesntContainSymbolicLinks()throws Exception
{
    WikiPage pageOne = crawler.addPage(root, PathParser.parse("PageOne"));
    crawler.addPage(root, PathParser.parse("PageOne.ChildOne"));
    crawler.addPage(root, PathParser.parse("PageTwo"));

    PageData data = pageOne.getData();
    WikiPageProperties properties = data.getProperties();
    WikiPageProperty symLinks = properties.set(SymbolicPage.PROPERTY_NAME);
    symLinks.set("SymPage", "PageTwo");
    pageOne.commit(data);

    request.setResource("root");
    request.addInput("type", "pages");
    Responder responder = new SerializedPageResponder();
    SimpleResponse response =
        (SimpleResponse) responder.makeResponse(
            new FitNesseContext(root), request);
    String xml = response.getContent();

    assertEquals("text/xml", response.getContentType());
    assertSubString("<name>PageOne</name>", xml);
    assertSubString("<name>PageTwo</name>", xml);
    assertSubString("<name>ChildOne</name>", xml);
    assertNotSubString("SymPage", xml);
}

public void testGetDataAsHtml() throws Exception{
    crawler.addPage(root, PathParser.parse("TestPageOne"), "test page");

    request.setResource("TestPageOne");
    request.addInput("type", "data");
    Responder responder = new SerializedPageResponder();
    SimpleResponse response =
       (SimpleResponse) responder.makeResponse(
            new FitNesseContext(root), request);
    String xml = response.getContent();

    assertEquals("text/xml", response.getContentType());
    assertSubString("test page", xml);
    assertSubString("<Test", xml);
}

在进展一番重构后,它长这么些样子代码8-2。

public void testGetPageHierarchyAsXml() throws Exception {
    makePages("PageOne", "PageOne.ChildOne", "PageTwo");

    submitRequest("root", "type:pages");

    assertResponseIsXML();assertResponseContains(
        "<name>PageOne</name>", "<name>PageTwo</name>", "<name>ChildOne</name>"
    );
}

public void testSymbolicLinksAreNotInXmlPageHierarchy() throws Exception {
    WikiPage page = makePage("PageOne");
    makePages("PageOne.ChildOne", "PageTwo");

    addLinkTo(page, "PageTwo", "SymPage");
    submitRequest("root", "type:pages");

    assertResponseIsXML();
    assertResponseContains(
        "<name>PageOne</name>", "<name>PageTwo</name>", "<name>ChildOne</name>"
    );
    assertResponseDoesNotContain("SymPage");
}

public void testGetDataAsXml() throws Exception {
    makePageWithContent("TestPageOne", "test page");

    submitRequest("TestPageOne", "type:data");

    assertResponseIsXML();
    assertResponseContains("test page", "<Test");
}

就像代码8-2中所示这样,测试代码应该是一个3段式:

  1. 预备测试数据。
  2. 必赢亚洲手机app,对测试数据举行操作。
  3. 展开判定。

世界专用语言

咱俩在编排测试的时候,最好不用直接使用标准代码中的API,而是应当在它们的底蕴上拓展打包,从而开创专用于测试的API,就像代码8-2中所示。

双重标准

对测试代码的要求和规范代码并不需要完全相同,可以应用双重标准来对待它们。测试代码仍旧必须要言简意赅而可读,不过不需要和业内代码这样拥有很高的运转效能(但同时测试也不可能效用太低,跑一回测试要等很久才清楚结果)。毕竟这个代码是跑在测试环境下,和标准环境抱有千差万别。

频率并不是测试代码的要紧目标,所以在编写测试代码时,可以牺牲局部大家在平时养成的出色习惯,而追求更好的可读性。比如在拼接字符串时(在测试代码中)就足以不使用StringBuilder,而一直利用+

一个测试只做一遍断言

假设可能,请遵从这一个规则,但它不应该改成您为了听从它,写了一大堆冗余的代码。

在可读性优秀的前提下,完全能够打破这条规则。

一个测试只有唯一的概念

相相比上一条,更客观的平整应有是,一个测试不应有包含两个概念的测试。比如代码8-3中就溢于言表违反了此标准,那么些测试要做的业务太多了,超出了一个定义的界定,应该将它分拆成3个测试。

//代码8-3
/*** Miscellaneous tests for the addMonths() method.*/
public void testAddMonths() {
    SerialDate d1 = SerialDate.createInstance(31, 5, 2004);

    SerialDate d2 = SerialDate.addMonths(1, d1);
    assertEquals(30, d2.getDayOfMonth());
    assertEquals(6, d2.getMonth());
    assertEquals(2004, d2.getYYYY());

    SerialDate d3 = SerialDate.addMonths(2, d1);
    assertEquals(31, d3.getDayOfMonth());
    assertEquals(7, d3.getMonth());
    assertEquals(2004, d3.getYYYY());

    SerialDate d4 = SerialDate.addMonths(1, SerialDate.addMonths(1, d1));
    assertEquals(30, d4.getDayOfMonth());
    assertEquals(7, d4.getMonth());
    assertEquals(2004, d4.getYYYY());
}

TDD中的「FIRST」原则

法斯特(Fast)(Fast):测试不可以每跑三次都要耗费大量的光阴。
Independent: 测试与测试期间不应当留存依靠关系。
Repeatable:
测试应该在任何环境下都能运行,不论是生产条件、测试环境,或者是在家里的台式机电脑上。
Self-Validating
测试的结果应该是肯定的,不应当是靠人去查看它的输出才能判定测试的功成名就与挫折。
提姆ely: 测试需要在正规代码往日就写好。

一经您的测试代码写的很烂,那么你的正规代码也将最后变得很烂。所以请保持你的测试代码整洁。

相关文章

No Comments, Be The First!
近期评论
    功能
    网站地图xml地图