NUnit快速入门(转)

简介:


51Testing 软件测试网
http://www.51testing.com/html/9/507.html

原著:NUnit v2.1
原文:NUnit文档之QuickStart.doc
翻译:lover_P
--------------------------------------------------------------------------------
[译者序]
    纵观软件的开发,测试已经日益成为软件开发过程中的重要环节,通常一个软件的开发周期中测试要占到一半时间甚至更多。而在测试过程中,单元测试更是万里长征第一步,单元测试进行得是否完善,直接影响到后期集成测试的效率。进行单元测试,有许多软件可以自动完成,NUnit就是其中之一。这是一款与JUnit齐名的,同属于xUnit家族的单元测试软件(在http://www.NUnit.org我们可以免费得到这款软件)。

[正文]

    让我们从一个简单的例子开始。假设我们正在编写一个银行应用程序,而我们有一个这一领域的基本类——Account。Account支持存款、取款和资金转帐。这个Account类看起来会是这个样子:

namespace bank {
    public class Account {
        private float balance;

        public void Deposit(float amount) {
            balance += amount;
        }

        public void Withdraw(float amount) {
            balance -= amount;
        }

        public void TransferFunds(Account destination, float amount) {
        }

        public float Balance {
            get {
                return balance;
            }
        }
    }
}

    现在我们来为这个类写一个测试——AccountTest。我们要测试的第一个类方法是TransferFunds。

namespace bank {
    using NUnit.Framework;

    [TestFixture]
    public class AccountTest {

        [Test]
        public void TransferFunds() {
            Account source = new Account();
            source.Deposit(200.00F);
            Account destination = new Account();
            destination.Deposit(150.00F);

            source.TransferFunds(destination, 100.00F);
            Assert.AreEqual(250.00F, destination.Balance);
            Assert.AreEqual(100.00F, source.Balance);
        }
    }
}

    首先要注意的是这个类关联了一个[TestFixture]特性(attribute)——这表示这个类包含了测试代码(这个特性可以被继承)。这个类必须是公有的,但他的父类并不受限制。这个类还必须有一个默认构造函数。

    类中唯一的一个方法——TransferFunds(),关联了一个[Test]特性——这表示它是一个测试方法。测试方法的返回值必须为void并且不能带有参数。在我们的测试方法中,我们对被测试的对象进行了一般的初始化,执行了被测试的方法并检查了对象的状态。Assert类定义了一组方法用于检查给定的条件,在我们的例子中我们使用了AreEqual()方法来确保交易过后两个账户都有正确的余额(这个方法有很多重载,我们在这个例子中使用的版本带有两个参数:第一个参数是我们的期望值,第二个参数是实际值)。

    编译并运行这个例子。假设你已经将你的测试代码编译为bank.dll。打开NUint Gui(安装程序会在你的桌面和“程序”菜单中建立一个快捷方式),打开GUI后,选择File->Open菜单项,找到你的bank.dll并在“Open”对话框中选中它。bank.dll装载后你会在左边的面板中看到一个测试树结构,还有右边的一组状态面板。单击Run按钮,状态条和测试树种的TransferFunds节点变成了红色——我们的测试失败了。“Errors and Failures”面板显示如下消息——“TransferFunds: expected <250> but was <150>”,在它正下方的堆栈跟踪面板报告了测试失败的语句在代码中的位置——“at bank.AccountTest.TransferFunds() in C:\nunit\BankSampleTests\AccountTest.cs:line 17”

    这正是预期的结果,因为我们还未实现TransferFunds()方法。现在我们来搞定它。不要关闭GUI,回到你的IDE并修改代码,使你的TransferFunds()方法看起来像这样:

public void TransferFunds(Account destination, float amount) {
    destination.Deposit(amount);
    Withdraw(amount);
}

    现在重新编译你的代码并再次在GUI中点击Run按钮——状态条和数节点变绿了。(注意GUI会自动地为你重新加载程序集;我们可以一直开着GUI而在IDE中继续工作并写更多的测试)。

    让我们来为我们的Account的代码添加一些错误检测。为账户添加一个最小余额限制,通过你的最小透支保护费来维持它的持续运作。首先我们来为Account类添加一个最小余额保护属性:

private float minimumBalance = 10.00F;

public float MinimumBalance {
    get {
        return minimumBalance;
    }
}

    我们使用一个异常来指出透支:

namespace bank {
    using System;

    public class InsufficientFundsException : ApplicationException {
    }
}

    向我们的AccountTest类添加一个新的方法:

[Test]
[ExpectedException(typeof(InsufficientFundsException))]
public void TransferWithInsufficientFunds() {
    Account source = new Account();
    source.Deposit(200.00F);
    Account destination = new Account();
    destination.Deposit(150.00F);
    source.TransferFunds(destination, 300.00F);
}

    这个测试方法除了[Test]特性之外还关联了一个[ExpectedException]特性——这指出测试代码希望抛出一个指定类型的异常;如果在执行过程中没有抛出这样的一个异常——该测试将会失败。编译你的代码并回到GUI。由于你编译了你的测试代码,GUI会变灰并重构了测试树,好像这个测试还没有被运行过(GUI可以监视测试程序集的变化,并在测试树结构发生变化时进行更新——例如,添加了新的测试)。点击“Run”按钮——我们又一次得到了一个红色的状态条。我们得到了下面的失败消息:“TransferWithInsufficentFunds: InsufficientFundsException was expected”。我们来再次修改Account的代码,象下面这样修改TransferFunds()方法:

public void TransferFunds(Account destination, float amount) {
    destination.Deposit(amount);

    if(balance - amount < minimumBalance)
        throw new InsufficientFundsException();

    Withdraw(amount);
}

    编译并运行测试——绿了。成功!不过等等,看看我们刚写的代码,我们会发现银行在每一笔不成功的转账操作时都亏钱了。让我们来写一个测试来确认我们的猜测。添加这个测试方法:

[Test]
public void TransferWithInsufficientFundsAtomicity() {
    Account source = new Account();
    source.Deposit(200.00F);
    Account destination = new Account();
    destination.Deposit(150.00F);

    try {
        source.TransferFunds(destination, 300.00F);
    }
    catch(InsufficientFundsException expected) {
    }

    Assert.AreEqual(200.00F,source.Balance);
    Assert.AreEqual(150.00F,destination.Balance);
}

    我们测试了方法的交易属性——是否所有的操作都成功了。编译并运行——红条。是的,我们平白无故地损失了300块钱——source账户有正确的余额150.00,但destination账户显示:$450.00。我们该如何修改?我们能够只将最小余额检查的调用放到数据更新的前面么:

public void TransferFunds(Account destination, float amount) {
    if(balance - amount < minimumBalance) {
        throw new InsufficientFundsException();
    }
    destination.Deposit(amount);
    Withdraw(amount);
}

    如果Withdraw()方法抛出了另外一个异常呢?我们应该在catch块中执行一个补救处理,还是依赖我们的交易管理器来重新装载对象的状态?某些时候我们必须回答这样的问题,但不是现在;可我们眼前如何应付这个失败的测试呢——删除它?一个不错的方法是临时忽略它在你的测试方法中添加下面的特性:

[Test]
[Ignore("Need to decide how to implement transaction management in the application")]
public void TransferWithInsufficientFundsAtomicity() {
    // code is the same
}

    编译并运行——黄条。单击“Test Not Run”选项卡,你会看到bank.AccountTest.TransferWithInsufficientFundsAtomicity()连同这个测试被忽略的原因一起列在列表中。

    看看我们的测试代码,我们可以看到一些适宜的重构。所有的方法共享一组公共的测试对象。让我们来将这些初始化代码放到一个setup方法中并在所有的测试中重用它们。我们的测试类的重构版本像下面这样:

namespace bank {
    using System;
    using NUnit.Framework;

    [TestFixture]
    public class AccountTest {
        Account source;
        Account destination;

        [SetUp]
        public void Init() {
            source = new Account();
            source.Deposit(200.00F);
            destination = new Account();
            destination.Deposit(150.00F);
        }

        [Test]
        public void TransferFunds() {
            source.TransferFunds(destination, 100.00f);

            Assert.AreEqual(250.00F, destination.Balance);
            Assert.AreEqual(100.00F, source.Balance);
        }

        [Test]
        [ExpectedException(typeof(InsufficientFundsException))]
        public void TransferWithInsufficientFunds() {
            source.TransferFunds(destination, 300.00F);
        }

        [Test, 
         Ignore (
            "Need to decide how to implement transaction management in the application"
        )]
        public void TransferWithInsufficientFundsAtomicity() {
            try {
                source.TransferFunds(destination, 300.00F);
            }
            catch(InsufficientFundsException expected) {
            }

            Assert.AreEqual(200.00F,source.Balance);
            Assert.AreEqual(150.00F,destination.Balance);
        }
    }
}

    注意这个初始化方法拥有通用的初始化代码,它的返回值类型为void,没有参数,并且由[SetUp]特性标记。编译并运行——同样的黄条!

============全文完==========

    如果你安装了NUnit V2.1,可以在 开始->程序->NUnit V2.1->QuickStart 处得到原文(英文版)。


推荐文章:
在.NET环境中使用单元测试工具NUnit
VS2005如何进行单元测试
DotNet的Attribute对单元测试的影响
C#单元测试



本文转自钢钢博客园博客,原文链接:http://www.cnblogs.com/xugang/archive/2008/02/21/1076489.html,如需转载请自行联系原作者

相关文章
|
3月前
【LVGL快速入门】LVGL开源框架入门教程之框架使用(三)
【LVGL快速入门】LVGL开源框架入门教程之框架使用(三)
133 1
【LVGL快速入门】LVGL开源框架入门教程之框架使用(三)
|
3月前
【LVGL快速入门】LVGL开源框架入门教程之框架使用(一)
【LVGL快速入门】LVGL开源框架入门教程之框架使用(一)
184 1
|
3月前
|
容器
【LVGL快速入门】LVGL开源框架入门教程之框架使用(二)
【LVGL快速入门】LVGL开源框架入门教程之框架使用(二)
188 1
|
6月前
|
设计模式 测试技术 Python
《手把手教你》系列基础篇(九十二)-java+ selenium自动化测试-框架设计基础-POM设计模式简介(详解教程)
【7月更文挑战第10天】Page Object Model (POM)是Selenium自动化测试中的设计模式,用于提高代码的可读性和维护性。POM将每个页面表示为一个类,封装元素定位和交互操作,使得测试脚本与页面元素分离。当页面元素改变时,只需更新对应页面类,减少了脚本的重复工作和维护复杂度,有利于团队协作。POM通过创建页面对象,管理页面元素集合,将业务逻辑与元素定位解耦合,增强了代码的复用性。示例展示了不使用POM时,脚本直接混杂了元素定位和业务逻辑,而POM则能解决这一问题。
73 6
|
6月前
|
设计模式 Java 测试技术
《手把手教你》系列基础篇(九十四)-java+ selenium自动化测试-框架设计基础-POM设计模式实现-下篇(详解教程)
【7月更文挑战第12天】在本文中,作者宏哥介绍了如何在不使用PageFactory的情况下,用Java和Selenium实现Page Object Model (POM)。文章通过一个百度首页登录的实战例子来说明。首先,创建了一个名为`BaiduHomePage1`的页面对象类,其中包含了页面元素的定位和相关操作方法。接着,创建了测试类`TestWithPOM1`,在测试类中初始化WebDriver,设置驱动路径,最大化窗口,并调用页面对象类的方法进行登录操作。这样,测试脚本保持简洁,遵循了POM模式的高可读性和可维护性原则。
57 2
|
6月前
|
设计模式 Java 测试技术
《手把手教你》系列基础篇(九十三)-java+ selenium自动化测试-框架设计基础-POM设计模式实现-上篇(详解教程)
【7月更文挑战第11天】页面对象模型(POM)通过Page Factory在Java Selenium测试中被应用,简化了代码维护。在POM中,每个网页对应一个Page Class,其中包含页面元素和相关操作。对比之下,非POM实现直接在测试脚本中处理元素定位和交互,代码可读性和可维护性较低。
46 0
|
8月前
|
测试技术 Python
Python测试架构unittest
【4月更文挑战第19天】
30 3
|
网络协议 安全 测试技术
单元测试快速入门 | 学习笔记
快速学习单元测试快速入门
|
Java Android开发 Kotlin
Kotlin练手,以登录为例,Anko简单使用
Kotlin练手,以登录为例,Anko简单使用
268 0
Kotlin练手,以登录为例,Anko简单使用
|
C# C++ 计算机视觉
Qt开发Activex笔记(一):环境搭建、基础开发流程和演示Demo
Qt开发Activex笔记(一):环境搭建、基础开发流程和演示Demo