無論是前后端分離開發，還是像我上述列出的前后端不是特別分離的jsp技術等，單元測試起到不可估量的作用。
我總結到，為什么表現層方面就會出現這樣的那樣的錯誤，關鍵在於控制層代碼有問題，也就是Controller層。
通常情況下，像我現在開發，通常Controller代碼，我會通過單元測試測試好幾遍，當然也做條件，這樣的話，可以避免一些簡單的錯誤，什么空指針，參數問題等等。而且對於表單提交方面的，例如注冊、添加用戶、批量增加或者修改等，都是可以通過單元測試測試是否正常。
記得某位朋友曾經說過，從單元測試到業務測試再到UI測試(WEB測試)，越底層，花費的時間成本越小，很容易找到錯誤，越到高層越不易排錯，當然了，排錯的方式也很重要。
這里我想說的是，盡量能在單元測試可以預見錯誤的前提下，盡量排錯錯誤的可能性，因為到WEB階段是非常讓人痛苦的。
越簡單的事情往往都會讓人忽略的，坦白地說吧，我發現一個很貼近現實的情況，就是我們開發人員，就我個人而言，有的時候覺得存在Bug，除非其他同事發現了，說了下，或者實際業務出問題，不然我不會改的，也懶得改。我想這是我半年前的心理。現在的我寫的代碼讓人盡可能容易讓同事看得懂，盡量簡潔，同時現在我對於我寫的代碼，我可以清楚地知道它是如何跑起來的，會出現哪些問題。當然了，對於一些簡單的低級錯誤，我現在已經通過單元測試排除掉了。而且再加上嚴格的表單校驗。統一規范的js書寫和每天十到十五分鍾早會的匯報和簡單交流及其加強溝通的情況下，我們的Bug越來越少了，代碼整體的性能也越來越好，簡潔優美，當然了，這還遠遠不夠，相對於第一個項目而言，我們的第二個項目一直到現在的第三個項目，越來越好了。希望繼續努力保持下去。
另外補充到:鄭州哪家精神病醫院好http://www.juenpt.com/
對於前后端交互，無論是AJAX或者vue.js等等，SpringMVC的Controller代碼，基本上都是可以通過單元測試得到結果的，單元測試過了，自然出錯率會減少很多。
當然了，我說的單元測試，不是簡單的運行就可以了，而是有條件的列出實際情況，這需要根據實際業務情況而定，當然了也不能總是在單元測試了，畢竟開發進度要保持增長。
總結:
上面的描述，也許不好理解，也許重點不突出。下面我要列出我認為重要的幾點?
(1)小公司而言，后台兼任前后台開發，確保后台參數，可以在前台校驗的，盡量放在前台，這對於減輕服務器負載非常有幫助;
(2)controller代碼中的各個@RequestMapping下的代碼是可以通過單元測試避免很多錯誤的，例如空指針或者sql有誤或者傳參類型問題或者resultType或resultMap常見的問題等，這些是可以避免的;
(3)寫代碼，無論是js或者Java代碼，一定要清楚的知道它是如何運行的，這里說的，並不是要你知道非常清晰的每一步,因為那是計算機底層原理，這個底層原理我也不懂，正在學習中。我所說的知道它是如何運行的，是指，你能通過大腦想象，描述它是怎么走了，比如這個參數傳到這個，但是參數值有誤，會出現什么情況等等這樣的情況，這樣可以確保你的思維是清楚，思維的清楚，也代表代碼邏輯的清楚。作為開發人員，連自己的代碼都不知道怎么描述，說不出所以然來，那么他的代碼是非常糟糕的;
(4)代碼，以追求簡單易懂，清楚明了為主，讓維護的人易維護，讓幾個月后的自己感謝自己。更讓整體系統性能更好。其實，很多簡單的事情堆積起來就是一件不平凡的事情。