根据我们上一节最后的投票。 引入unittest框架 碾压了第一种。其实我个人也偏向这个。因为我尝试过很多，但是唯独没有引入unittest在接口测试平台中。所以借此机会，也想挑战一下，涨点经验。
请注意：目前博主是完全完全没这个设计和实现过的状态，和正在看此文章的你一样，让我们感受最原始的设计思路。
首先我们打开views.py，找到我们写了个开头的这个实际请求的函数：
既然要引入unittest，那我们这块可能要想到，这么一个测试类，是否应该放在其他文件呢？ 我觉得可以试一试一会。
这里我们从数据库中先拿到所有步骤，然后这些步骤我们利用循环，让其自动生成这个测试类的 子函数。然后运行这个unittest测试类即可。
这个过程如果不经过讲解，很难看明白来龙去脉。
我们先新建一个其他文件，作为unittest的主要运行文件。而当前的这个views.py 就会履行它真正的作为视图逻辑的交互责任，就是整理过滤前端请求数据，传递给业务层。
我们在贴着views.py的位置 创建一个新的文件叫: run_case.py：
好了我们继续，用过unittest的人都知道我下面的写法吧：
非常简单的一个unittest demo。
我们现在就是要想办法，调用这个文件，启动这个unittest
我们现在来想个问题，就是我要怎么调用，并且，还能带着参数-一群步骤
那么现在看这个写法，应该没法带参数，甚至没法调用。因为我们要引入httptestrunner，所以我们正好可以利用起来，具体操作如下：
首先下载并导入这个HTMLTestRunner 文件。
然后代码如下：
这时候我们运行这个run的话，就会执行这个用例，并且生成xxx.html测试报告。
不过我们不在这里运行，而是选择去views.py中调用这个run()函数来运行。
所以这个views.py写法如下：
然后我们重启服务 刷新页面，点击运行按钮 看看效果：
可以看到 成功运行了，并且生成了测试报告：
只是这个报告目前 位置我们还没有设计好，所以默认生成在这了。
右键这个html，选择open in broswer，选择你的浏览器 看看效果：
大家请忽略报告中的一些文案～ 后续我会放上纯净版的这个HTMLTestRunner.py文件。
然后就是我们本节的结尾，就是给这个报告放在指定位置：
在templates包下新建一个名为Reports的包，用来存放我们的测试报告：
然后别忘了删除我们刚刚调试生成的那个报告，记得及时清理这些垃圾。
然后在我们的run函数中，改写这个filename：
然后我们重启服务 再试一次：
发现这次报告生成在了 应该出现的位置。
最后我们顺便再做一下这个查看报告的功能吧，早做出来也早方便我们调试。
打开P_cases.html，找到这个查看报告按钮,给它外面套一层a标签。超链接按图中所写：
然后我们去写好对应的urls.py：
最后去写好对应的views.py中的函数：
我们这时候要思考一个问题，我们怎么来让这些生成的报告文件 能与 用例关联起来而不至于错乱呢？
最简单的办法，我们的html文件就干脆用大用例id来命名即可。所以我们代码如下：
如上图，我直接返回了这个html。
现在我们需要的就是让我们unittest自动生成的这些报告都以大用例的id来命名吧，这也就说了回来，我们一开始要对unittest的run函数传递数据，除了各种小步骤之外，还要传递大数据的id name等。以便生成清晰的报告。
所以这么改 Run_Case函数：
然后去unittest的文件的run函数接收好这俩个参数：
然后再想办法 拼接到生成的报告文件的名称中：
好，我们重启服务，刷新页面再测试：
测试结果显示，这个大用例id为1的 报告生成成功了！
然后我们再点击 页面上的查看报告按钮，看看能否展示：
发现也可以正常展示了！
好了本节内容到此为止。
大家不要忘记分享，点赞，在看 这些啊～
