A. controller单元测试
可以使用MockMVC对Controller进行测试
<dependency>
<groupId>org.springframework.restdocs</groupId>
<artifactId>spring-restdocs-mockmvc</artifactId>
<version>2.0.1.RELEASE</version>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-test</artifactId>
<scope>test</scope>
</dependency>
举个栗子
B. 如何进行前端自动化测试
没人邀请，路过回答。
前端测试是前端工程方面的重要分支，有过一些探索，这里简单分享一下。
首先，还是要强调一点：
前端是一种特殊的GUI软件
看过我最近一年内做前端工程方面相关分享的人可能有印象，我总是在强调这一点。前端测试也跟这个理论基础有所关联。
在这里，我还想吐槽一下：
API测试方法论在测试GUI时并不能解决所有问题。
与很多前端工程师讨论过前端测试，大家更多的还是盯着API测试方法论。诚然，前端有那么一小部分代码是可以用API测试保证质量的，但前端项目中的绝大多数代码是GUI界面，前端测试应该向传统GUI测试方法论需求解决方案：GUI软件测试_网络 ，这个网络词条介绍的很不错，大家可以感受一下GUI测试相关概念和方法。它的测试用例、覆盖率统计、测试方法等等都与API测试有着很大的不同。
统一了这个认知之后，我们来讨论一下前端GUI测试的特殊性。根据网络词条上的那些介绍，相信大家都能感觉到GUI测试的成本非常高，而前端这种特殊的GUI软件，具有天生的快速迭代特征，这使得case维护成本也变得非常高，经常跟不上迭代速度。
一
个标准的互联网应用产品的前端部分，我粗略估计大概有20%的业务基础代码比较稳定，比如通用组件、通用算法和数据模块等，可以针对这些建立复杂一些的
API和GUI测试用例来保证质量。剩下80%的部分不是很稳定，每天都在迭代，针对他们维护case的成本非常高。目前业界中号称做了自动化测试的项
目，也大多是在做那稳定的20%。
关于稳定部分的单元测试方法我这里就不赘述了， @貘吃馍香 的答案给出了很多关键字，有兴趣的去搜索就好了。我想讨论的是针对剩下80%不稳定部分的工程化测试方案。据我了解，前端测试面对这些问题还是很无力的，业内大部分团队还是靠堆人解决。
面对这种现状，我其实也没想到过什么好的方法，基本原则就是：以最低的成本建立和维护自动化测试用例。到目前为止，就想到过两个方案（都不是测试方案，只是回归测试辅助）：
1. 不太靠谱的“超级工位”大法。
这个方案可以说根本不是什么技术方案，而是一个办公设施，就是我们准备一个工位，摆上所有我们需要测试的主流设备，然后设备通过某种方式与一台电脑相连接，测试人员坐在工位上，在电脑中输入某个url，就能同步到所有设备中，然后开始逐个的人肉测试。
超级工位大法示意图（应该很多设备的，这里就是随便展示一下而已。。。）超级工位大法示意图（应该很多设备的，这里就是随便展示一下而已。。。）
相比现在的前端GUI测试，超级工位已经算是从0到1的飞跃了，虽然没解决什么技术问题，但为测试前的准备工作做好了铺垫。如果把前端测试比作吃屎，超级工位就是为这餐准备了一个好一点的餐桌。。。
2. 靠谱一些的“页面差异监控”
12
年的时候还在网络，当时有同事去美国参加velocity，twitter分享了一下他们的开发流程，其中有一个环节就是页面对比监控，利用了一个叫
pdiff的工具，每次提交代码，会自动对比页面之间的差异然后提醒测试人员注意回归。这也是一个典型的GUI测试零成本维护用例的案例。不过pdiff
这个工具是基于像素对比的，误报率比较高，所以去年我做了一个这个项目：fouber/page-monitor · GitHub 基于DOM树的diff，这样就能很大程度上自主控制要监控的元素，可以设置监控样式、文本的变化，比起像素diff智能了一些。
其
工作原理就是利用phantom或其他headless浏览器访问页面，然后截图，然后执行一段js，遍历整个dom树，获取元素计算样式和元素内文本内
容，构造出一个JSON结构，然后每次diff这个json来判断页面差异，并标记在截图上展示。dom树的diff过程有点类似react的虚拟dom
树diff。
（react的dom树diff算法示意图）（react的dom树diff算法示意图）
（react的dom树diff算法示意图）（react的dom树diff算法示意图）
DOM树diff我们可以分辨出元素样式修改/内容修改/新增元素/删除元素四种不同的页面差异，我们可以配置选择器来忽略元素。四种页面差异的效果图：
新增元素（绿色区域标记部分，“i am new here”）新增元素（绿色区域标记部分，“i am new here”）
删除元素（灰色区域标记部分，“你好”）删除元素（灰色区域标记部分，“你好”）
内容修改（黄色区域标记部分，“百-度”，“新-浪”）内容修改（黄色区域标记部分，“百-度”，“新-浪”）
样式修改（红色区域标记的部分）样式修改（红色区域标记的部分）
基于这样的页面差异对比监控，我们可以建立一个任务系统，把应用的所有页面url监控起来，这样每次版本迭代提交代码后，系统就能自动告诉我们，哪些页面的元素展现发生了改变，用于确定回归范围。
用监控的方式确定测试回归范围，是一种“少吃屎”的手段，符合工程化要求，能比较大范围的应用，虽然不能完美解决GUI中的交互问题，但能保证GUI的展现问题已经是不小的进步了。
C. 刚进一家公司，这个公司有人专门写前端，我是java写后台，我想问测试的时候怎么搞
自己写个简单的页面，去测试，或者如果是struts可以写action的测试用例的
~~~~~~~~~~
D. 前端的代码code review工具有没有推荐
首先，我们先来看看Code Reivew的用处：
Code reviews 中，可以通过大家的建议增进代码的质量。
Code reviews 是一个传递知识的手段，可以让其它并不熟悉代码的人知道作者的意图和想法，从而可以在以后轻松维护代码。
Code reviews 也鼓励程序员们相互学习对方的长处和优点。
Code reviews 也可以被用来确认自己的设计和实现是一个清楚和简单的。
你也许注意到了在上面的Code Reivew中的诸多用处中，我们没有提到可以帮助找到程序的bug和保证代码风格和编码标准。这是因为我们认为：
Code reviews 不应该承担发现代码错误的职责。Code Review主要是审核代码的质量，如可读性，可维护性，以及程序的逻辑和对需求和设计的实现。代码中的bug和错误应该由单元测试，功能测试，性能测试，回归测试来保证的（其中主要是单元测试，因为那是最接近Bug，也是Bug没有扩散的地方）
Code reviews 不应该成为保证代码风格和编码标准的手段。编码风格和代码规范都属于死的东西，每个程序员在把自己的代码提交团队Review的时候，代码就应该是符合规范的，这是默认值，属于每个人自己的事情，不应该交由团队来完成，否则只会浪费大家本来就不够的时间。我个人认为“meeting”是奢侈的，因为那需要大家在同一时刻都挤出时间，所以应该用在最需要的地方。代码规范比起程序的逻辑和对需求设计的实现来说，太不值得让大家都来了。
10年前，上面这两件事会是理所当然的（10年前的中国的软件开发还没有Code Reivew呢），今天，在中国的很多公司上面这两件事依然被认为是Code Reivew最重要的事，所以，我能够看到很多开发Team抱怨Code Review就是一个形式，费时费力不说，发现的问题还不如测试，而评审者们除了在代码风格上有些见术，别的也就没什么用了，长而久之，大家都会开始厌烦这个事了。
所以，在今天，请不要把上面的那两件事分散了Code Review的注意力，取而代之的是，对于Bug，程序的作者要在Review前提交自己的单元测试报告（如：XUnit的测试结果），对于代码规范，这是程序作者自己需要保证的，而且，有一些工具是可以帮你来检查代码规范的。
E. 前端测试工具有哪些 ja
javaScript 是一款强大的广泛运用于现代Web站点及应用的脚本语言。作为一个技艺精湛的 Web 开发者，尤其是前端开发工程师，掌握JavaScript可以增强用户的使用体验，提供交互及富客户端等功能。
尽管JavaScript 的语法非常简单，但对于写程序而言仍然是困难重重，就是因为它的运行环境：基于Web浏览器。
以下您可以看到收集的8个实用的 JavaScript 测试及效验工具，它们都可以在不同环境下进行单元测试及校验测试您的脚本。
JSLint
JSLint是基于Web的验证JavaScript错误代码的工具。它拥有的功能及特定的设置来使用您的需求，自定义你的验证算法。
JsUnit
JsUnit是一款在客户端(在浏览时)的单元测试JavaScript框架。对JavaScript而言，JUnit就像是它的一个端口。当然它也可以在多 个浏览器、多个机器的不同操作系统中自动运行。它的发展始于2001年1月。
J3Unit
J3Unit是一个面向对象的JavaScript单元测试框架。J3Unit在网页浏览器中直接运行JavaScript的测试，也可以自动运行 JUnit 和 Jetty。J3Unit是建立在JUint和Script.aculo.us的基础之上来更好地实现自动运行JavaScript 单元测试。面向对象的JavaScript单元测试是由Script.aculo.us的Test.Unit.Runner对象编写的，基于 prototype JavaScript库。
Crosscheck
Crosscheck是一款开源的校验浏览器中的JavaScript测试框架。它可以帮助您在不同的浏览器中，诸如：Internet Explorer、Firefox等，而不需要一 一安装他们来确认您的代码是否正确。您唯一需要的是必须要有Java虚拟机环境。
YUI Test
YUI测试是一款基于浏览器，提供解决方案的测试框架。使用YUI，您可以方便地添加单元测试，寻求JavaScript解决方案。它是由 Yahoo! UI Library开发的一个JavaScriptMVC测试插件，能够让你模范大部分DOM动作，比如写，拖拽，比如模范AJAX响应，并且能够使用断言 (assertions)。它能够象函数一样运行，并且能够在不同的console窗口进行集成测试。虽然它不是在任何 xUnit 框架基础上开发而来，但YUI Test仍然有很多nUnit 和 JUnit的所具有的特性。（ While not a direct port from any specific xUnit framework, YUI Test does derive some characteristics from nUnit and JUnit. 这段翻译得不好，但相信大致意思是对的）。
Regular Expression Tool
Regular Expression Tool（正则表达式工具）是一款在线工具，用来测试您的正则表达式代码是否正确。当您想快速测试各种文本例子的正则表达式时非常得心应手。
JSLitmus
JSLitmus是款轻量级的工具，用来测试JavaScript执行性能情况，采用直观的API。
JavaScript Regular Expression Tester
这块便利的应用程序是在浏览器中使用JavaScript来测试JavaScript正则表达式的。操作界面跟其他正则表达式测试工具无异，不同的 是，它测试的是JavaScript正则表达式在JavaScript中的性能情况。
F. 怎么对vue中$emit进行单元测试
网页链接可以参考官方文档。
其实前端一般如果涉及到页面改动的话，就建议直接运行在页面进行观察测试。而
$emit显然都已经涉及到父子组件的问题，所以我建议可以不用写单元测试，直接在页面出发调用就行了。
G. 搞前端开发你们弄单元测试么
根据招聘网站显示，web前端高级工程师的岗位职责如下：
1、熟悉、理解并掌握公司系统的架构、技术和开发工作。
2、参与公司系统的需求分析、产品讨论。
3、能独立完成应用系统的开发、自测试、联调以及上线发布。
4、系统的单元测试工作。
5、配合测试工程师完成集成测试工作。
6、协助运营、产品等相关人员维护已上线版本。
任职要求:
1、深刻理解互联网应用系统的架构和主流技术,如React Native、VueJS框架。
2、熟练掌握Html5、CSS、JavaScript。
3、熟练掌握VueJS前端技术框架,并有相关的项目经验。
4、能够独立完成前端应用的开发、打包、联调及发布工作。
5、3年以上前端开发经验,有较好的沟通能力和团队合作能力。
6、对ES6熟悉,有跨平台开发经验者优先
码教授有这方面的经验可以为您解答
H. 什么是单元测试意义是什么
单元测试是什么
单元测试是开发者编写的一小段代码，用于检验被测代码的一个很小的、很明确的功能是否正确，通常而言，一个单元测试是用于判断某个特定条件（或者场景）下某个特定函数的行为
单元测试的好处
1，单元测试不但会使你的工作完成得更轻松。而且会令你的设计会变得更好，甚至大大减少你花在调试上面的时间 2，提高代码质量 3，减少bug，快速定位bug 4，放心地修改、重构
写单元测试要注意什么
1，不能只测试一条正确执行路径，要考虑到所有可能的情况
2，要确保所有测试都能够通过，避免间接损害
3，如果一个函数复杂到无法单测，那就说明模块的抽象有问题
4，配置不是单元测试的难点，难点是mock（后文讲），做单元测试需要伪造被测函数用到的大部分函数
为什么写单元测试
编写单元测试太花时间了？考虑下面问题：
1，对于所编写的代码，你在调试上面画了多少时间？
2，对于以前你自认为正确的代码，而实际上这些代码却存在重大的bug，你画了多少时间在重新确认这些代码上面？
3，对于一个别人报告的bug，你花了多少时间才找出导致这个bug的源码位置？
对于那些没有使用单元测试的程序员而言，上面这些问题所耗费的时间的递增速度是很快的，而且随着项目深入，递增速度会变得更快；而另一方面，适当的单元测试却可以很大程度地减少这些时间，从而为你腾出足够的时间来编写所有的单元测试——甚至可能还有剩余的空闲时间。
I. 如何在前端开发中应用tdd和单元测试
驱动函数就是要用来调用被测函数的，当被测函数不能直接运行时，就需要一个驱动其运行的函数，比如说main函数，或者别的可以将这个函数运行起来以便于你来测试的函数。
与其对应的还有一个桩函数的概念，顾名思义就是相对底层的东西了，测试上层的函数的时候，由于被测函数需要调用到相对底层的一些函数，当底层函数比较复杂时，就可以考虑自己做一个简单的被调用函数来替换原来的底层函数，前提是不会太大的影响你要测试的代码。这个就是桩。
J. 自动化单元测试工具目前常用的有哪些
自动化测试包含多种，如Web自动化、手机自动化等：
Web自动化测试工具：selenium、QTP。
性能自动化测试工具：loadrunner、jmeter。
接口自动化测试工具：SoapUI、postman。
手机自动化测试工具：robotium、appium。
每种的第一个都比较推荐。当然还有其他的工具，不过这些比较普及。