单元测试,该如何解决
单元测试
如何对网站（C#）进行单元测试？，新手，想自学下，一直都是手动测试，所以想做下单元测试
------解决方案--------------------
单元测试是对某个部分的代码进行测试，首先你要学会单元测试的理论，以及单元测试的方法
你要是自己想做单元测试的小项目的话，推荐你先了解测试的整个流程，从大的角度理解单元测试，再学习一下白盒测试的方法，白盒测试是单元测试的一个主要常见方法
最后可以针对c#语言的特点寻找相关工具，vs2010可以进行操作。
------解决方案--------------------
首先，你要是一个编程高手。
其次，你应该深刻地理解web通讯以及dom、javascript等原理。因为你需要去深入到底层的回调机制、dom树去编程。
最后，你要从需求出发，仔细研究每一个用户行为模式而编程，而不是纠缠什么“单元”这个死的、围绕编程人员的概念。自动化测试要从需求行为出发，能不纠缠于什么编程单元的就不要纠缠于编程单元。从系统验收的细节出发，才是自动测试的本质。
------解决方案--------------------
所谓“单元测试”只是几十年前的一种工具而已。从15年前敏捷开发开始兴起，自动化测试不是针对什么“函数或者方法”的。你进行测试，就要从功能接口、团队多人协作，甚至用户界面交互验收角度去写测试代码。也就是用代码去写测试用例（而不是留下不可自动执行的测试用例文档）。
如果你纠结空洞的“函数、方法”概念，那么这些东西就是你的借口，你只会的等到写完代码去瞎糊弄一下。其实几乎没有什么人真正会在写完代码之后立刻就去怀疑自己的代码，更不会去写出全面的自动测试代码。
写自动测试，要在你写执行代码之前，在你刚刚制定了模块接口得时候。也就是说，你写测试时基于“时间基线”的，例如你打算为自己未来一个小时、或者团队4个小时所要向svn服务器提交的成果——实现的功能接口——进行测试。你是在实际去编写实现这些功能之前写一个用7、8个断言来描述的测试用例，而不是在实际去编写是实现这些功能之后去写什么针对其内部函数或者方法去的单元测试。
实际上架构经常变化，而测试不变。所以你经常删除一些内部的函数和方法，来重构。自动测试就是用来保证你有勇气去做重构，来完成性能或者功能的飞跃。所以千万不要仅仅把自动测试的“单元”理解为地低级而空洞的编程函数、方法，一定要从“编程时间、接口、验收、进度”这些角度来理解进行测试驱动的意义！
如何对网站（C#）进行单元测试？，新手，想自学下，一直都是手动测试，所以想做下单元测试
------解决方案--------------------
单元测试是对某个部分的代码进行测试，首先你要学会单元测试的理论，以及单元测试的方法
你要是自己想做单元测试的小项目的话，推荐你先了解测试的整个流程，从大的角度理解单元测试，再学习一下白盒测试的方法，白盒测试是单元测试的一个主要常见方法
最后可以针对c#语言的特点寻找相关工具，vs2010可以进行操作。
------解决方案--------------------
首先，你要是一个编程高手。
其次，你应该深刻地理解web通讯以及dom、javascript等原理。因为你需要去深入到底层的回调机制、dom树去编程。
最后，你要从需求出发，仔细研究每一个用户行为模式而编程，而不是纠缠什么“单元”这个死的、围绕编程人员的概念。自动化测试要从需求行为出发，能不纠缠于什么编程单元的就不要纠缠于编程单元。从系统验收的细节出发，才是自动测试的本质。
------解决方案--------------------
所谓“单元测试”只是几十年前的一种工具而已。从15年前敏捷开发开始兴起，自动化测试不是针对什么“函数或者方法”的。你进行测试，就要从功能接口、团队多人协作，甚至用户界面交互验收角度去写测试代码。也就是用代码去写测试用例（而不是留下不可自动执行的测试用例文档）。
如果你纠结空洞的“函数、方法”概念，那么这些东西就是你的借口，你只会的等到写完代码去瞎糊弄一下。其实几乎没有什么人真正会在写完代码之后立刻就去怀疑自己的代码，更不会去写出全面的自动测试代码。
写自动测试，要在你写执行代码之前，在你刚刚制定了模块接口得时候。也就是说，你写测试时基于“时间基线”的，例如你打算为自己未来一个小时、或者团队4个小时所要向svn服务器提交的成果——实现的功能接口——进行测试。你是在实际去编写实现这些功能之前写一个用7、8个断言来描述的测试用例，而不是在实际去编写是实现这些功能之后去写什么针对其内部函数或者方法去的单元测试。
实际上架构经常变化，而测试不变。所以你经常删除一些内部的函数和方法，来重构。自动测试就是用来保证你有勇气去做重构，来完成性能或者功能的飞跃。所以千万不要仅仅把自动测试的“单元”理解为地低级而空洞的编程函数、方法，一定要从“编程时间、接口、验收、进度”这些角度来理解进行测试驱动的意义！