单元测试用例

[慕容柳生]

c#中如何编写某个文件（许多类组成）的单元测试用例

[gytice]

你指的是不是别人写的DLL啊，这样的话应该会有public的方法，然后进去调用就行了，可以在控制台写，也可以用nunit进行多个用例测试

[以专业开发人员为伍]

引用 楼主 andysunlover 的回复:

c#中如何编写某个文件（许多类组成）的单元测试用例

如果仅仅为了形式，那么你可以为每一个方法和属性，写一个单元测试方法。 不过单元测试仅仅是一个方法而已，如果你懂得TDD之类的概念，那么测试就是一个设计过程，而不是跟在实现代码（某个具有许多类的文件写完之后）屁股后边去撵人家的。如果你有一点TDD知识你就会知道，通常程序员在写完代码之后就不愿意写测试了，因为谁也不愿意在刚刚费精力写好代码之后直接就怀疑和否定自己的代码。你把一个简单的问题搞得这个纠结和无头绪，就是这个原因。 因此，微软vs工具中的所谓“单元测试”传递的是一个误导性的概念。如果你采取TDD（注重测试从而去驱动出开发结果）方式来开发，真正的单元测试是你在设计阶段写下来的，这个时候你还没有开始那些“某个文件（许多类组成）”中的可执行代码。而不是写完这些之后才写单元测试。 鉴于你现在的情况，我给你一个建议，你可以假设“某个文件（许多类组成）”全都可以推翻，现在重新进行设计，于是你就可以轻松上阵真正开始写TDD式的单元测试代码了。 进行测试驱动开发，是以“时间进度”为标准的。例如你打算最近一个小时干什么、明天上午10点应该达到什么目标、如果17天之后发布非客户的话那么最重要的10个系统集成测试要求是什么，你预先把这些写成可执行的东西（而不是毫无可执行能力的所谓“文档”）。你在实际写代码之前先写测试。编程是很低级的工作，编程的目的不过为了让测试能够通过。测试才是软件开发的根本。

[以专业开发人员为伍]

如果17天之后发布非客户的话那么最重要的10个 --> 如果17天之后发布给客户的话那么最重要的10个 技术说成概念，看似谁都会。但是一旦实用，很多人就有“只会konw-what不会know-how”了。

[wanghui0380]

的确如同老p说地，单元测试这东西基本在设计阶段就得去保证，起码我设计的这个东西，能不能出正常结果，我的先验证一下。尤其在做初始架构阶段，抽象类是否能运作，是否能达到以后的应对变化，这个我自己心里要有数。（这也是俺们很多时候批评那些搞设计模式的人的主要原因，设计是动态的，并且是需要验证滴，不是你背书然后就那么“设计”出来了） 而最终形成结果的东西，在程序员这里就很少测试了，因为设计期已经验证过了，至于太过具象的业务实现那些边界条件覆盖一类的东西，程序员们很少测试，这个有专门的测试小组去搞，这块不是大方向的问题，都是已经隔离好的细节，你测试小组测试出bug了可以随时替换修改，所以那些比较细致的边界条件覆盖一类的测试让专业的测试小组去弄就可以了，你还有更重要的事情要忙呢

[缪军]

确认需求的时候就应该有测试用例了,这样能够明确的向客户和开发者说明业务规则和验收方法