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。
每種的第一個都比較推薦。當然還有其他的工具，不過這些比較普及。