MVC单元测试

[qq_30254253]

MVC单元怎么测试页面传来的属性 比如读写Cookies,Request.Form。单元测试都是没有页面 这些属性怎么传进去。

[以专业开发人员为伍]

写微软的单元测试的那些人不太懂 UI 程序的机制，它们更多地是把自间的软件的界面搞好（给你弄一个赏心悦目的测试结果报告），因为他们有的是人力啊。而实际上启动一个项目设计最关键，最需要知识和创意。后边都是招一些美工和普通产品人员不断优化的事情。 它们会在文档中告诉你“asp.net mvc 容易测试啊！因为只要测试 Controller 就行了”这种话。 你若想模拟用户的页面中的操作，甚至用1个小时时间（你去吃中午饭的时间）去让程序以随机顺序模拟几百遍不同的测试用例（没一个测试用例都是模拟了用户5、6步网页操作，而不是一步），你就需要能对整个页面前端编程。例如，使用 WebBrowser 为基础来开发测试用例，将编写这样的测试用例中常用的一些通用功能（例如查找dom元素，记录执行步骤日志，捕获dom变化，模拟点击，模拟鼠标拖动，等待上一步执行完毕或者超时异常，等等）写到自己的类库中。 也有一些基于网页然后嵌入 IFrame 的测试引擎。不过自己使用 WebBroser 这类也就很轻松了，自己写几十行c#作为核心代码，比网上下载的看不懂用不精养不熟的东西都适合。

[以专业开发人员为伍]

使用 WebBrowser 之后，因为你封装了测试引擎，你就可以轻松地写上几行代码就能指定任意多个“并发测试”，来模拟任意多个浏览器窗口并发但独立操作。 一般来说，任何都是有着验证漏洞的。必须进行多线程并发测试，才能保证服务端程序的可靠。

[以专业开发人员为伍]

任何都是有着验证漏洞的 --> 任何顺序测试都是有着严重漏洞的 并发、大乱次序。在这种情况下，（比如说）50个测试用例被执行了1000遍（每一个测试用例都分别模拟用户的多个顺序操作），这样的网站才敢上线啊。 而大多数小公司，其实就是程序员稀里糊涂、浑浑噩噩地把编译后的网站扔到服务器上，然后等着出问题。上线前并没有这类测试。