刚刚译了 NDoc，又一次深入学习了 Reflection 反射发出、XSLT 转换，还学习了很多关于 HTML Help 1、Microsoft Help 2 等帮助文件的制作细节。
手中的项目客户点名要求使用 NDoc (日语版) 和 NUnit。前者当然是为了最终有一个漂亮的类库文档。后者则是 TDD 开发的标志物。
我想，日本人对文档的重视程度是国内开发人员所难以想象的。以往的项目，并不采用 TDD 开发，所谓单元测试(Unit Test)，最主要也最耗时的工作就是在那里拼凑“测试文档”，用大量的文字、表格、屏幕截图等等，证明 coding 没问题、输出是正确的；而并非真正的按照单元测试的要求、分 class/function 执行测试。
而按照典型的 TDD 开发，如果再如此这般的折腾“测试文档”，那可就完蛋了，因为 TDD 是测试先行，反复的执行“回归测试”……但测试总得有文档，否则怎么证明你测试了？如果每次回归都要文档，那就有些惨了。另外客户也要求单元测试的文档包含在最终交付物中。
也是因为刚译完 NDoc 的缘故，所以第一个念头就是：是否有一款能够配合 NUnit 自动生成“测试文档”的小工具？
NDoc 现有的体系是：从程序集(*.dll/exe)及其相应的 XML 文档文件(*.xml) 开始，最终输出代码文档。
而 NUnit 也可以将测试结果以 XML 文件保存下来。
如果混合一下，从程序集(*.dll/exe)及其相应的 XML 文档文件(*.xml)，再加上 NUnit 的测试结果 XML 文件，最终输出“测试文档”？
哎，一个新的工具就是这么“诞生”(？)了。可以使用和参考大量 NDoc 的现有代码。不过 NDoc 现在是 GPL 协议授权，也就是这个衍生物也必须是 GPL 的了。这点有些不爽，说实话，我喜欢 BSD，不太喜欢 GPL。抽时间再想吧，要睡觉了~
打印 | 张贴于 2005-10-09 23:46:00 | Tag:暂无标签
留言反馈
不要对别人塞给你的商业软件抱太高期望，当你真正想用的时候就会发现满足不了你的需求但你又没有地方抱怨，甚至什么都做不了。NUnit有bug至少我可以改，但商业软件给你有bug你能做什么呢？等待人家给你一个都不知道会不会出现的patch吗？
更多的时候我更觉得使用第三方商业程序要比使用开源的风险大的多，因为开源的我随时都可以改，高兴怎么改怎么改，内部是怎么运作的我都了解，但是商业程序我就无能为力了，只能榨尽脑汁想workaround的方法，其结果就是因为第三方的不尽人意导致了我的程序在设计编码上也不尽人意（因为诸多的workaround）。
没问题，绝对支持命令行^_^另外你的这个想法我以前所在的一家公司做过，不过是内部使用，所以我绝对支持你的想法！如果你要做成开源的话我很乐意帮忙^_^
谢谢！
不过和我想象的不太一样，看了它的 Sample 输出，它只是生成了测试结果的文档。
我想的是，让它把关于 Test Case 的设计文档（就是每个 Test Case 的目的是什么，Test Case 中做了 Assert 验证）也包含在内。
其实我的想法是按 NDoc 的思路：在写 Test Case 代码的时候，通过 XML 文档注释，将这些设计信息写在源代码中，
比如使用
/// <summary>
/// 这个测试用例用于测试 <see cref="XXXXX.Common.TextUtil.Filter" /> 方法。
/// </summary>
/// <assert>验证一，......</assert>
/// <assert>验证二，......</assert>
/// <author>破宝</author>
[Test]
public void TestFilter()
{
......
}
然后通过提取出来的 XML 注释，结合程序集 Reflection 的信息，以及 NUnit 的 XML 报告，
三者合一，制作出 Test Case 设计文档/测试结果都在一起的文档。
能否举些 NUnit 报表生成工具的例子呢？我刚刚接触 NUnit 没多久，不太了解。如果有合适的现成工具，我也不必麻烦了。
另外，关于这个设想，一个思路是集成在 NDoc 里面，做成一个 NDoc 文档引擎(documenter)；另一个思路，就是另外做一个专门的 NUnitDoc 的东西，这样，也可以让它像 NDoc 一样，有多种文档引擎输出多种不同样式的测试文档格式。
NUnit不知道什么时候release下一个版本，目前它的扩展性太差。:(