急求写过测试代码的大神来醍醐灌顶
0
悬赏园豆：5
[待解决问题]
我怀疑标题有点病句。。。
最近因为老大要求，需要对app的接口数据请求部分写单元测试，我在这里想问一下逻辑性问题：
我们的项目列表数据请求分为有token和没有token两种情况，我需要把这两种情况都测试一下，那么我怎么才能在运行测试代码的时候获得有效的token呢？
我想到的解决办法有两种：1 先执行一下登陆代码，获得有效token，然后去进行请求项目列表数据
2 让后台给我一个永远不过期的token测试用
第一种方法感觉比较繁琐，因为很多接口都用到了token这个参数，第二个方法据说不太靠谱
这种情况我要怎么来写测试用例呢？给位大神请给指点一下！
所有回答(2)
0
单元测试本来就是一套全新的代码，你如果想好点的话就采用第一点，看过的一段精彩的文章对单元测试最后的总结：
所以，于我而言，单元测试是否有价值的争论可以休矣！不如换个角度，想一想，怎样才能把单元测试坚持下去。
最后，如果有心的同学就会注意到，我一直用的是“单元测试”，而不是“测试驱动”。因为测试驱动是一个更广阔的概念，是一个更崭新的天地！单元测试只是其中的一小部分，在下一篇博客，我会讲解我是如何试着将测试驱动的概念运用到项目开发管理中去的。这里，需要强调的一点：先写测试。
一上手就写开发代码，写完了才写单元测试。这是很多开发人员的习惯，我也经常犯这样的毛病，一不留神就忘了。这样做最大的问题就是，没有真正实现“测试驱动”。你实际上还是由开发在驱动，那么很自然的，测试照着开发的if...else...写一遍，有什么意义呢？这样做下去，就会不断的强化“测试无用累赘”的印象，因为测试就是简单的把开发代码重写一遍而已。我开的药方是：
- 单元测试代码和开发代码由不同的人员编写
- 如果做不到上面一点，先写单元测试
- 如果连上面一点也做不到，直到出了bug了再写单元测试
第三条可能有同学无法理解，不是说单元测试很重要么？为什么要等到出了bug才写？答案是：偷懒呗！记住，我们程序员是世界上最懒的人，没意义的事从来不做！你先写开发代码再写测试真的没意义，没意义就干脆不要做了。但你可以开启“乐观模式”（或者“Lazy模式”？），先乐观的认为，我的代码没问题，或许真的就没问题呢，是吧？如果真出了问题，做一个补救，这个时候就应该用单元测试把这个问题表现出来，因为他根据墨菲定律，它这里出了问题，以后就很有可能继续出问题。这个时候，就不要再偷懒了。
0
有两个思路给你：
一、微软官方在提到MVC的 控制器（c-Controller）单元测试的时候，用的是抽像类、接口封装，然后通过IOC（依赖注入、控制反转）的方式，在单元测试实际运行的时候进行实例化。这样的话，对于需要登录之后使用的、有token的控制器类、方法，可以在实体创建的时候，添加了token然后再调用类和方法。
相应的内容我是在这本书《ASP.NET MVC 3 高级编程》上看到的，刚刚搜了一下这本书，然后看到第10章、第11章，就是说这些的。
网上也有PDF版本，你可以自己找来看一看。
二、我自己的方法。
需要token的页面置于同一个基类之下，比如说AdminPageBase。或者需要token的控制器置于同一个基类之下，比如说BaseController。然后在基类里面添加一个绕过登录的方法，比如说：SkipLogin()，在这个方法里面，创建token，比如说Session[“Username"]="admin"。
这样你在单元测试的方法里面，可以先调用SkipLogin，然后再调用需要token的方法。
当然，这样做的话就出来一个严重的安全性问题，接下来你需要使用各种手段屏蔽掉SkipLogin了。
比如说在SkipLogin方法当中加上条件编译，只允许debug模式返回token,比如说，限制IP，只允许IP为127.0.0.1时候返回token。
比如说在MVC模式下给SkipLogin加上过滤器，限定这不是一个action方法。
比如说加在HttpHandler上限制出现SkipLogin，一旦URL出现SkipLogin跳转到不样干的地方。
再比如说，SkipLogin这个名字，你换成一个除了你以外谁也不知道的字符串，然后你也只在单元测试使用，除此以外再也不用。。。。。
