單元測試的基本概念：
對軟體中的最小可測試單元進行檢查和驗證
①單元的定義：**中可度量的最小單元（函式、方法）
②檢查和驗證：不同的輸入對應的輸出是否與預期一致
1.要進行單元測試首先需要知道單元測試需要的幾個基本原則：
①自動化：單元測試應該是全自動執行的，非互動式的。
②非相互依賴：單元測試方法的執行順序不應該影響執行結果，各個方法之間不應該相互依賴。
③多設定斷言：盡量多設定斷言，把需要測試的結果都進行測試。
④結果唯二：單元測試只能有兩種結果，通過或失敗。
2.單元測試的基本流程：
①arrange 準備階段：設定前提條件，比如初始化物件、模擬資料等等。
②act 行為階段（執行動作）：呼叫被測試的方法，並得到返回結果。
③assert 斷言階段（驗證結果）：把呼叫目標方法返回的值和預期的值進行比較，如果和預期一致說明測試通過，否則就是失效。
3.單元測試示例
以c#平台的msunit測試框架演示
①簡單模擬乙個使用者類及種子資料
②準備寫好待測試的生產**（以客戶端開發常用的單例舉例）
③編寫單元測試
4.異常捕獲測試
一些底層專案需要丟擲異常，這種情況下我們需要對相應的異常也做出測試。
mock在單元測試中是乙個很重要的概念，
mock是模擬的意思，mock框架就是用來模擬物件的乙個技術。一般在一下幾種情況下用：
①真實物件具有不確定行為（比如不可**的結果，類似**）
②物件很難被建立
③物件的某些行為很難觸發（例如網路錯誤）
④測試需要驗證某個**函式是否被呼叫
⑤物件並不存在（多端的情況下或者和其他專案或服務打交道的時候）
以moq框架為例，假設我們現在需要通過乙個公司物件獲取到該公司旗下的所有遊戲，該方法依賴乙個公司物件。
但是，這個公司物件以介面形式用公司名稱獲取，我們並不知道介面實現和公司資料庫。
這時，我們就可以用moq模擬乙個公司倉儲的例項，並設定好一些輸入對應的輸出結果。
「2」中的意思也就是說，當針對這個方法輸入「南山必勝客」的時候，方法會返回returns裡面的物件。（例子不好，但是這麼個意思）
「南山必勝客」懂得都懂
最後可以執行測試，得到測試結果。當我們看到一片綠的時候，心情是不是舒暢很多呢：）
1.單元測試能解決的問題
①提高**質量：
對於每個最小的單元，針對不同輸入對應的輸出可以和預期結果做對比，減少因為引數導致的異常問題，**變得更加健康，增加新需求時不用擔心影響原來**邏輯。
②**耦合度低、模組化：
若要對乙個模組單元進行單元測試，需要將每個單元拆分得相對獨立，使得**的邏輯、結構清晰，減少單元之間的依賴。**出現bug更容易定位。
③**可重用：
經過單元測試的**，既穩定又獨立，可以更加方便的在其他專案或者專案重構時重複利用。
④**可讀性強：
單元測試某種程度上相當於系統的文件。借助於檢視單元測試提供的功能和單元測試中如何使用單元，開發人員可以直觀的理解每個單元的功能。
2.單元測試的缺點
①浪費開發時間（寫單元測試需要大量的時間，不如直接寫具體的實現），有些模組根本無法進行單元測試（無返回值的方法、ui介面）
②不能發現整合錯誤、效能問題、或者其他系統級別的問題。單元測試結合其他軟體測試活動更為有效。
單元測試還是應該多搞，不為別的，就為了看到那一片綠色，嘿嘿...
Excel要不要「引」
雙引號在excel公式中無處不在，我們有必要了解它的用法。一 什麼時候需要加 1 表示空字元。if a1 a1 10 意思是如果a1的值為空，則顯示空白，否則返回a1 10 2 字串 表示文字，在公式中文字兩邊都需要加雙引號。countif a a,abc 意思是統計a列的為 abc 的個數。3 日...
要不要冗餘字段
這個問題我糾結了老長時間，至今仍未想明白。但是與其萬馬齊喑不如胡說八道。如果使用者表新增計數字段，好處在於用空間換時間，查詢速度肯定快多了 如果追求簡潔無冗餘，好處在於清晰易懂，寫 不蔓不枝，特別漂亮。如果不設計冗餘字段，也慢不了多少，建立完外來鍵或者索引之後查詢速度會提公升很多。如果覺得這麼整寫s...
要不要造輪子？
在it界，有一句很經典的話 不要重複造輪子！我們要敏捷開發，快速迭代。這句話意思是說在已有技術可以解決需求的前提下我們不需要再重新實現乙個模組來實現功能，哪怕這個技術是第三方的。在當下，網際網路產品迭代更新的階段，公司業務需求變更頻繁，編碼與搬磚無異，這句話被很多人奉為圭臬，甚至是很多人 指導思想 ...