破宝

我是一块破破烂烂的宝贝石头。
随笔 - 85, 评论 - 1279, 引用 - 54

导航

工具

关于

自选精华版 RECOMMENDATIONS
留言板 GUESTBOOK

本人 blog 文章、图片及其他资源等,除另有声明外,均遵循以下原则向全球(当然包括朝鲜、古巴、利比亚等国)共享:

1。欢迎转载、复制、传播、引用,但转载、复制(包括但不仅限于作为参考资料复制到本地)、传播、引用同时必须在显著位置注明作者(破宝/percyboy)和文章原始 URL 地址等信息。但商业转载、复制、传播(尤指用于图书、光盘等媒体的部分或全部),须事先征得本人的许可。

2。文章以“现状”提供,不为由于使用本站资源而造成的任何损失而负责,仅提供力所能及的咨询和参考意见。

3。关于修改:允许您将本 blog 中的资源作为参考资料复制时的一定修改,但仍须保留作者和出处信息;其他情况下的修改(包括修改后再发布),须和本人确认许可。
 

标签

每月存档

广告



访客

 

继上一篇文章谈到 NDoc for NUnit 的初步构想之后,继续构想......

首先,给这个构想中的工具暂定个名字叫 NUnitDoc。这个工具的预定目标是,以 NDoc 的设计和部分代码为基础,综合

(1) 包含 NUnit 测试用例的程序集(*.dll/*.exe)文件;
(2) 开启 C# 编译器 /doc 开关,输出的相应 XML 文档文件(*.xml);
(3) NUnit 执行的结果 XML 文件(*.xml)

这三种文件中的信息,合并并制作出漂亮的测试文档。(1) 和 (2) 同样是 NDoc 所需要的,(3) 是 NUnit 所生成的。

需要感谢 CavingDeep 网友和我探讨这个构想。他给我介绍了几款可以根据 NUnit 生成 HTML 报表的工具,但我看了一些它们的输出 Sample 之后,认为它们不是我想要的东西。它们都是只利用了 NUnit 输出的结果 XML 文件,因此制作的 HTML 报表中,只包含关于测试结果的信息,并不包括关于测试用例的文档信息。

下面,我来具体描述一下我的构想:首先,在 TestFixture 标记的类的相关方法(标记有 Test 的方法)的代码上方,为它们编写一些注释信息(就和为 NDoc 编写注释类似的方法),比如下面的代码:

[TestFixture]
public class TextUtilTest
{
	private TextUtil util = null;

	/// <summary>用例开始前,初始化 <b>TextUtil</b> 的一个新实例。</summary>
	[Setup]
	public void Setup()
	{
		util = new TextUtil();
	}

	/// <summary>此用例用于测试 <b>TextUtil</b> 类的 <b>IsValidEmailAddress</b> 成员。

</summary>
	/// <asserts>
	/// <assert>输入一个合法的 Email 地址,验证返回值是否为 <b>true</b>。</assert>
	/// <assert>输入不含有 '@' 符号的字符串,验证返回值是否为 false。</assert>
	/// <assert>输入以 '@' 符号开头的字符串,验证返回值是否为 false。</assert>
	/// <assert>输入以 '@' 符号结尾的字符串,验证返回值是否为 false。 </assert>
	/// <assert>输入一个只含有 '@' 符号的字符串,验证返回值是否为 false。</assert>
	/// <assert>输入一个 '@' 符号前面包含空格的字符串,验证返回值是否为 false。</assert>
	/// <assert>输入一个 '@' 符号前面包含空格的字符串,验证返回值是否为 false。</assert>
	/// <assert>输入一个 '@' 符号后面包含空格的字符串,验证返回值是否为 false。 </assert>
	/// <asserts>
	[Test]
	public void TestIsValidEmailAddress()
	{
		Assert.IsTrue(util.IsValidEmailAddress("xxx@xxx.com"));
		Assert.IsTrue(util.IsValidEmailAddress("xxxx.com"));
		Assert.IsTrue(util.IsValidEmailAddress("@xxx.com"));
		Assert.IsTrue(util.IsValidEmailAddress("xxx@"));
		Assert.IsTrue(util.IsValidEmailAddress("@"));
		Assert.IsTrue(util.IsValidEmailAddress("xx xx@xxx.com"));
		Assert.IsTrue(util.IsValidEmailAddress("xxx@xxx com"));
	}

	/// <summary>用例运行结束后,抛弃测试前创建的 <b>TextUtil</b> 实例。</summary>
	[TearDown]
	public void TearDown()
	{
		util = null;
	}
}

最终生成的测试文档中,该测试用例的页面显示如下图的效果:

不早了,睡觉~~ 继续欢迎大家一起讨论我的构想!

相关文章

Loading...

打印 | 张贴于 2005-10-12 00:18:00 | Tag:暂无标签

留言反馈

#re: NUnitDoc 继续构想(2) 编辑
@破宝
FreeTextBox 在每次回发后,Height 都会在默认值的基础上减小一些,这是为啥呢?
2006-03-28 17:30:00 | [匿名用户:proshea]
#re: NUnitDoc 继续构想(2) 编辑
虽然我刚刚接触.net和TDD,很多东西都不太明白。但是对楼主的想法非常支持!我们就是需要这样创新的东西!加油!:)
2006-01-06 11:40:00 | [匿名用户:ivan]
#re: NUnitDoc 继续构想(2) 编辑
很不错的创意,期待
2005-10-20 10:17:00 | [匿名用户:JACKY]
#re: NUnitDoc 继续构想(2) 编辑
Good idea!
2005-10-18 17:44:00 | [匿名用户:wayfarer]
#re: NUnitDoc 继续构想(2) 编辑
我想这个完全可以通过对NDoc的标签进行扩展来实现,我想应该包括这些工作:
1.自定义一套XML标签,用于在测试代码中编写注释;如果可能,最好能够和IDE集成(输入“///”就能够下拉列表选择);
2.XML文档的生成在项目编译的过程自动生成,不需要再做特殊处理;
3.自定义用于NDoc转换的XSLT转换文档,用于将自定义的标签转换为Html;可能最好能够编写为NDoc的Generator,可以在NDoc GUI中进行选择的;
4.最后就是使用NDoc生成lz所需要的文档;这个过程中应该就不需要什么处理了。
2005-10-12 18:32:00 | [匿名用户:NetCobra]
#re: NUnitDoc 继续构想(2) 编辑
这个应该叫测试报告吧?测试报告常常会有,所以自动生成很重要。
2005-10-12 09:40:00 | [匿名用户:Ninputer]
#re: NUnitDoc 继续构想(2) 编辑
Cool!
以下是我认为单元测试用例必须拥有的基本信息:

1. 描述,描述用例要测什么。
2. 步骤,描述测试时所做的步骤。
3. 期望,也就是期望的测试结果。

单元测试用例不同于其他普通测试用例,它不必/不会有用例ID、前置条件;另外我觉得检查点(Check Point)应该是可选的,不是必须要写在文档中的内容,在看这份测试用例文档时我们主要关心的,是用例的作用、步骤、期望以及实际结果。

还有就是输出结果,实际上单元测试有三种结果:成功、失败与异常。在输出文档中要能够体现并区分这三种结果。

其他的就是不那么重要的了,目前我觉得这几部分比较关键。:)
2005-10-12 09:21:00 | [匿名用户:Cavingdeep]
#re: NUnitDoc 继续构想(2) 编辑
很不错的想法啊,支持
2005-10-12 08:47:00 | [匿名用户:fans1]
对不起,目前本随笔不允许发表新评论.

Powered by: Joycode MVC Blogger System