问题描述
为什么这么多人使用单元测试呢？比如说[TestMethod]publicvoidTestStoredProcedure(){}自己写一个方法调用一下不就行了吗？为什么要单元测试呢？不是多此一举吗？还是有其它什么做用？望高人指点！！小弟感激不尽...
解决方案
解决方案二：
1.要保证自己的代码是尽可能不出错的，所以要单元测试2.单元测试的方法往往是写在单独的类里，因为它和实际编写的代码逻辑上功能不同，自己写一个方法测试一下只适用于小的练习
解决方案三：
经典之作《代码大全》中的单元测试---单元测试在软件质量中的作用测试对任何一个软件质量来说是重要的,在许多场合，它只是其中一部分。这是不幸的，因为评审的各种方式证明，它们比测试要能发现更多的错误，而且评审发现每个错误所花费仅为测试的一半左右(Card1987)。单个测试方法(单元测试、功能测试、部分测试、系统测试)，通常只能发现少于50％的错误数。几种测试方法的集成使用，只会发现少于60％的错误（Jones1986）。然而,由于测试已被广泛使用，而且它比评审要能发现更多种类型的错误，因此它应该测试对任何一个软件质量来说是重要的,在许多场合，它只是其中一部分。这是不幸的，因为评审的各种方式证明，它们比测试要能发现更多的错误，而且评审发现每个错误所花费仅为测试的一半左右(Card1987)。单个测试方法(单元测试、功能测试、部分测试、系统测试)，通常只能发现少于50％的错误数。几种测试方法的集成使用，只会发现少于60％的错误（Jones1986）。然而,由于测试已被广泛使用，而且它比评审要能发现更多种类型的错误，因此它应该较好的。当然如果了解盒子的内部情况，你就可更仔细地测试你的子程序，至少你有更多的机会发现错误。和不熟悉代码者相比较，你处在发现错误的更有利位置上。在创建过程中，你编写子程序，对其进行手工检查，然后评审或测试它。不论你的集成或系统测试策略如何，在你将其合并之前，你应仔细地测试每个单元。如果你在编写几个子程序，你应不时测试一下它们。单个测试子程序并不容易，但是要调试它们是容易的。如果你马上将未测试的子程序组合起来并且发现了错误，那么其中任何一个子程序都有可能有错误。如果你每次将一个子程序加进已经测试过的子程序中，你就能知道任何一个新错误可能是由新的子程序或者是由新、旧子程序的相互作用所引起的。这时，使用调试方法较为简单。参考http://www.cntester.com/root/Tech/Unit/546.html
解决方案四：
mark
解决方案五：
和“自己写一个方法调用一下”不同的是...单元测试是需要遵循规范的，必须是可控制和可管理的...它的好处除了保证代码的质量还可以获得更加深入的结果，例如代码覆盖率数据，开发团队可以合并测试结果并在生成测试报告等...认为“多此一举”的想法证明你仍然停留在手工作坊时代...
解决方案六：
还是不太明白。。唉写单元测试不是很浪时间吗？
解决方案七：
vs2005里有工具可以帮你生成单元测试的代码
解决方案八：
提前错误的发现时间,避免以后浪费资源和提高成本,这个只能用单元测试拉.相当相当重要
解决方案九：
提前错误的发现时间,避免以后浪费资源和提高成本,这个只能用单元测试拉.相当相当重要
解决方案十：
我的理解是这样的：如果要写出高质量的代码，就应该进行单元测试，这样才能保证代码的强壮性在实际工作中，需要维护的项目非常有必要进行单元测试，这样会从总体上节约开发时间