VS2013单元测试(使用VS2013自带的单元测试)

简介:
1、打开VS3013,随便建一个解决方案,比如叫:LearnUnitTest,建一个类库项目LearnUnitTest_Bank,该项目中添加一个BankAccount类,这个类及类中的方法就是我们要 测试的对象。
  2、给LearnUnitTest添加一个测试项目:在解决方案名称上右键=》添加=》新建项目=》VisualC#=》测试=》 单元测试项目,项目名称叫LearnUnitTest_BankTest,将LearnUnitTest_Bank添加为LearnUnitTest_BankTest的引用项目,将测试项目LearnUnitTest_BankTest里默认生成的类重命名为BankAccountTest。
  对于BankAccountTest类,类上有注解TestClass,方法上有注解TestMethod。可以在这类文件里添加其他类和方法,供测试方法使用。
   首个测试:
  3、现在我们测试BankAccount类的Debit方法,我们预先确定此次测试要检查如下方面:
  a、如果信用余额(credit amount)比账户余额大,该方法就抛异常ArgumentOutOfRangeException
  b、如果信用余额小于0也抛异常
  c、如果a和b都满足,该方法会从账户余额里减去amount(函数参数)
  注意:由a、b、c可以看邮BankAccount类中的Debit方法最后一行应该是-=,而不是+=——当然了,这个是故意留下的bug,而不是 微软的失误,就等着在这次测试中把它测出来,然后修正掉。
  在测试类里添加如下方法测试Debit方法:
// unit  test code
[TestMethod]
public void Debit_WithValidAmount_UpdatesBalance()
{
// arrange
double beginningBalance = 11.99;
double debitAmount = 4.55;
double expected = 7.44;
BankAccount account = new BankAccount("Mr. Bryan Walton", beginningBalance);
// act
account.Debit(debitAmount);
// assert
double actual = account.Balance;
Assert.AreEqual(expected, actual, 0.001, "Account not debited correctly");
}
   测试方法的要求:
  必须要有TestMethod注解,返回类型为void,不能有参数。
  经过测试,我们发现了bug,把+=改为-=即可。
  使用单元测试改善代码:
  依然是测试Debit,本次测试想完成以下意图:
  a、如果credit amount(指的应该就是debit amount)比balance大,方法就抛ArgumentOutOfRangeException
  b、如果credit amount比0小,也抛ArgumentOutOfRangeException异常
   (1)创建测试方法
  首次尝试创建一个测试方法来处理上述问题:
  代码:
//unit test method
[TestMethod]
[ExpectedException(typeof(ArgumentOutOfRangeException))]
public void Debit_WhenAmountIsLessThanZero_ShouldThrowArgumentOutOfRange()
{
// arrange
double beginningBalance = 11.99;
double debitAmount = -100.00;
BankAccount account = new BankAccount("Mr. Bryan Walton", beginningBalance);
// act
account.Debit(debitAmount);
// assert is handled by ExpectedException
}
  注意这个方法:Debit_WhenAmountIsLessThanZero_ShouldThrowArgumentOutOfRange,意思是:当debit amount小于0时,本次测试应该会导致被测试的方法抛出ArgumentOutOfRange异常,否则本次测试就失败了,没有达到期望,需要修改Debit代码以达成本次测试期望——正所谓TDD开发。
  我们使用了ExpectedExceptionAttribute特性来断言期望的异常应当被抛出。除非方法抛出ArgumentOutOfRangeException异常,否则该特性就会导致测试失败(要注意本次测试的意图)。用正的和负的debitAmount运行这个测试,然后临时把被测试的方法(Debit方法)修改一下:当demit amount小于0时抛出一个ApplicatinException。捣腾完这些,发现本次测试基本没什么问题。
  为了测试debit amount 大于balance的情形,我们做下面几个操作:
  a、创建一个新的测试方法名叫    Debit_WhenAmountIsMoreThanBalance_ShouldThrowArgumentOutOfRange
  b、从上一个测试方法
  Debit_WhenAmountIsLessThanZero_ShouldThrowArgumentOutOfRange
  复制方法体到本测试方法
  c、把debitAmount设置为一个比balance大的值
   (2)运行测试方法
  用不同的debitAmount值运行Debit_WhenAmountIsMoreThanBalance_ShouldThrowArgumentOutOfRange
  和 Debit_WhenAmountIsLessThanZero_ShouldThrowArgumentOutOfRange
  然后运行三个测试,这样我们最开始设定的三个cases都被覆盖了。
  (3)继续分析
  后面两个测试方法Debit_WhenAmountIsMoreThanBalance_ShouldThrowArgumentOutOfRange
  和Debit_WhenAmountIsLessThanZero_ShouldThrowArgumentOutOfRange
  有些问题:两个测试运行的时候根据抛出的异常,你不知道是谁抛出的,靠ExpectedException特性做不到这件事。
  可以这样修改:
  在类里定义两个常量:
// class under test
public const string DebitAmountExceedsBalanceMessage = "Debit amount exceeds balance";
public const string DebitAmountLessThanZeroMessage = "Debit amount less than zero";
// method under test
// ...
if (amount > m_balance)
{
throw new ArgumentOutOfRangeException("amount", amount, DebitAmountExceedsBalanceMessage);
}
if (amount < 0)
{
throw new ArgumentOutOfRangeException("amount", amount, DebitAmountLessThanZeroMessage);
}
// ...
   (4)重构测试方法
  首先,移除ExpectedException特性。取而代之的处理是:我们捕获异常,来核实是在哪种条件下抛出的。
  修改一下Debit_WhenAmountIsMoreThanBalance_ShouldThrowArgumentOutOfRange
  方法:
[TestMethod]
public void Debit_WhenAmountIsGreaterThanBalance_ShouldThrowArgumentOutOfRange()
{
// arrange
double beginningBalance = 11.99;
double debitAmount = 20.0;
BankAccount account = new BankAccount("Mr. Bryan Walton", beginningBalance);\
// act
try
{
account.Debit(debitAmount);
}
catch (ArgumentOutOfRangeException e)
{
// assert
StringAssert.Contains(e.Message, BankAccount. DebitAmountExceedsBalanceMessage);
}
}
   (5)再次测试,再次重写,再次分析
  当我们用不的参数再次运行测试方法Debit_WhenAmountIsMoreThanBalance_ShouldThrowArgumentOutOfRange
  的时候,会遇到下面一些问题:
  1、如果我们使用一个比balance大的debitAmount运行,产生的测试结果是所期望的。
  2、如果使用了一个debitAmount运行,使得assert 断言失败了(比如在Debit方法的某一行返回了一个非期望的异常),也没什么问题,在本测试的情理之中。
  3、如果debitAmount是有效的(比0大比balance小)会发生什么呢?没有异常抛出,断言也不会失败,测试方法通过了。——这不是我们想要的,注意我们此次的测试初衷:要么断言成功,要么断言失败,如果压根进入不了断言代码,只能说明测试方法写的问题!
  为了解决这个问题,我们在测试方法的最后一行加入一个Fail断言,来处理没有异常发生的情况:没有异常发生,就说明此次测试没有达到期望!
  但是修改好再次运行,会发现如果所期望的异常被捕获了,测试总会失败。为了解决这个问题,我们在StringAssert之前加一个return。
  最终我们的Debit_WhenAmountIsMoreThanBalance_ShouldThrowArgumentOutOfRange
  方法如下:
[TestMethod]
public void Debit_WhenAmountIsGreaterThanBalance_ShouldThrowArgumentOutOfRange()
{
// arrange
double beginningBalance = 11.99;
double debitAmount = 20.0;
BankAccount account = new BankAccount("Mr. Bryan Walton", beginningBalance);\
// act
try
{
account.Debit(debitAmount);
}
catch (ArgumentOutOfRangeException e)
{
// assert
StringAssert.Contains(e.Message, BankAccount. DebitAmountExceedsBalanceMessage);
return;
}
Assert.Fail("No exception was thrown.")
}
  最终我们让测试代码变得更加强健,但更重要的是,在这个过程中,我也们也改善了被测试的代码——这才是测试的最终目的。

最新内容请见作者的GitHub页:http://qaseven.github.io/
相关文章
|
8天前
|
测试技术 开发者 UED
探索软件测试的深度:从单元测试到自动化测试
【10月更文挑战第30天】在软件开发的世界中,测试是确保产品质量和用户满意度的关键步骤。本文将深入探讨软件测试的不同层次,从基本的单元测试到复杂的自动化测试,揭示它们如何共同构建一个坚实的质量保证体系。我们将通过实际代码示例,展示如何在开发过程中实施有效的测试策略,以确保软件的稳定性和可靠性。无论你是新手还是经验丰富的开发者,这篇文章都将为你提供宝贵的见解和实用技巧。
|
3月前
|
JSON Dubbo 测试技术
单元测试问题之增加JCode5插件生成的测试代码的可信度如何解决
单元测试问题之增加JCode5插件生成的测试代码的可信度如何解决
53 2
单元测试问题之增加JCode5插件生成的测试代码的可信度如何解决
|
2月前
|
IDE 测试技术 持续交付
Python自动化测试与单元测试框架:提升代码质量与效率
【9月更文挑战第3天】随着软件行业的迅速发展,代码质量和开发效率变得至关重要。本文探讨了Python在自动化及单元测试中的应用,介绍了Selenium、Appium、pytest等自动化测试框架,以及Python标准库中的unittest单元测试框架。通过详细阐述各框架的特点与使用方法,本文旨在帮助开发者掌握编写高效测试用例的技巧,提升代码质量与开发效率。同时,文章还提出了制定测试计划、持续集成与测试等实践建议,助力项目成功。
82 5
|
3月前
|
JSON 测试技术 数据格式
单元测试问题之使用JCode5插件生成测试类如何解决
单元测试问题之使用JCode5插件生成测试类如何解决
117 3
|
3月前
|
测试技术
单元测试问题之使用TestMe时利用JUnit 5的参数化测试特性如何解决
单元测试问题之使用TestMe时利用JUnit 5的参数化测试特性如何解决
45 2
|
3月前
|
测试技术 C# 开发者
“代码守护者:详解WPF开发中的单元测试策略与实践——从选择测试框架到编写模拟对象,全方位保障你的应用程序质量”
【8月更文挑战第31天】单元测试是确保软件质量的关键实践,尤其在复杂的WPF应用中更为重要。通过为每个小模块编写独立测试用例,可以验证代码的功能正确性并在早期发现错误。本文将介绍如何在WPF项目中引入单元测试,并通过具体示例演示其实施过程。首先选择合适的测试框架如NUnit或xUnit.net,并利用Moq模拟框架隔离外部依赖。接着,通过一个简单的WPF应用程序示例,展示如何模拟`IUserRepository`接口并验证`MainViewModel`加载用户数据的正确性。这有助于确保代码质量和未来的重构与扩展。
73 0
|
3月前
|
测试技术 Java Spring
Spring 框架中的测试之道:揭秘单元测试与集成测试的双重保障,你的应用真的安全了吗?
【8月更文挑战第31天】本文以问答形式深入探讨了Spring框架中的测试策略,包括单元测试与集成测试的有效编写方法,及其对提升代码质量和可靠性的重要性。通过具体示例,展示了如何使用`@MockBean`、`@SpringBootTest`等注解来进行服务和控制器的测试,同时介绍了Spring Boot提供的测试工具,如`@DataJpaTest`,以简化数据库测试流程。合理运用这些测试策略和工具,将助力开发者构建更为稳健的软件系统。
54 0
|
3月前
|
测试技术 Java
全面保障Struts 2应用质量:掌握单元测试与集成测试的关键策略
【8月更文挑战第31天】Struts 2 的测试策略结合了单元测试与集成测试。单元测试聚焦于单个组件(如 Action 类)的功能验证,常用 Mockito 模拟依赖项;集成测试则关注组件间的交互,利用 Cactus 等框架确保框架拦截器和 Action 映射等按预期工作。通过确保高测试覆盖率并定期更新测试用例,可以提升应用的整体稳定性和质量。
73 0
|
3月前
|
测试技术 数据库
探索JSF单元测试秘籍!如何让您的应用更稳固、更高效?揭秘成功背后的测试之道!
【8月更文挑战第31天】在 JavaServer Faces(JSF)应用开发中,确保代码质量和可维护性至关重要。本文详细介绍了如何通过单元测试实现这一目标。首先,阐述了单元测试的重要性及其对应用稳定性的影响;其次,提出了提高 JSF 应用可测试性的设计建议,如避免直接访问外部资源和使用依赖注入;最后,通过一个具体的 `UserBean` 示例,展示了如何利用 JUnit 和 Mockito 框架编写有效的单元测试。通过这些方法,不仅能够确保代码质量,还能提高开发效率和降低维护成本。
49 0
|
3月前
|
Java 测试技术 API
SpringBoot单元测试快速写法问题之复杂的业务逻辑设计有效的单元测试如何解决
SpringBoot单元测试快速写法问题之复杂的业务逻辑设计有效的单元测试如何解决