軟件工程師爲何要懂測試

       作爲軟件開發工程師必定要懂測試. 你不懂你的全局觀還不夠. 架構師須要理解測試. 你不懂測試你不會理解測試過程痛, 不能友好的與測試工程師協做. 你不測試說明你的LEVEL還不夠高, 對於軟件質量理解還不夠.  遠的測試過程不說, 先說說單元測試UT. 不少開發工程師, 什麼高大上微服務項目都作過了, 仍是寫很差單元測試. 單元測試這是一個普通的技能了. 你寫很差, 說明你不專業. 閱讀如下內容讓咱們專業點兒:

      一. 測試的價值

        Tests help us catch mistakes. Tests help us shape our design to actual use.

       注意詞Shape,  再者是

Tests help us avoid gold-plating by being explicit about what the required behavior is.

         不少測試因素直接或間接影響 產出效率, 以下圖

    測試也是個設計工具, 迭代的思想:

 

    TDD思想出來了, 循環迭代, 有時候與咱們作成一件事過程也是相同的.

      二. 測試不要依賴真實數據庫
        使用內存數據庫, 以下的實踐

• Substitute test doubles for third-party library dependencies, wrapping them with your own adapters where necessary. The tricky stuff is then encapsulated inside those adapters that you can test separately from the rest of application logic. 
• Keep test code and the resources they use together, perhaps in the same package. 
• Let test code produce the resources it needs rather than keeping them separate from the source code. 
• Have your tests set up the context they need. Don’t rely on any other tests being run before the one you’re writing. 
• Use an in-memory database for integration tests that require persistence, as it greatly simplifies the problem of starting tests with a clean data set. Plus, they’re generally superfast to boot up. 
• Split threaded code into asynchronous and synchronous halves, with all application logic in a regular, synchronous unit of code that you can easily test without complications, leaving the tricky concurrency stuff to a small, dedicated group of tests.

     咱們在Test double 概念中也看到 Fake 對象說起 內存數據庫

• Dummy objects are passed around but never actually used. Usually they are just used to fill parameter lists.
• Fake objects actually have working implementations, but usually take some shortcut which makes them not suitable for production (an InMemoryTestDatabase is a good example).
• Stubs provide canned answers to calls made during the test, usually not responding at all to anything outside what's programmed in for the test.
• Spies are stubs that also record some information based on how they were called. One form of this might be an email service that records how many messages it was sent.
• Mocks are pre-programmed with expectations which form a specification of the calls they are expected to receive. They can throw an exception if they receive a call they don't expect and are checked during verification to ensure they got all the calls they were expecting.

     還有一句有意思話

Friends Don't Let Friends Hit The Database In Tests

     其它BLOG, 還有

Lightweight, drop-in replacement for the database

Aside from substituting a test double for your data access object, the next best thing might be to use a lightweight replacement for your database. For instance, if your persistence layer is built on an ORM framework and you don’t need to hand-craft SQL statements, it likely doesn’t make much of a difference whether the underlying database product is an Oracle, MySQL, or PostgreSQL. In fact, most likely you should be able to swap in something much more lightweight an in-memory, in-process database such as HyperSQL (also known as HSQLDB). The key advantage of an in-memory, in-process database is that such a lightweight alter native conveniently avoids the slowest links in the persistence chain the network calls and the file access.

    

   So far you’ve  learned that unit tests should stay away from the network  interface  and the filesystem if execution speed is a factor. File I/O isn’t exclusive to database.

      Separate Dependencies Where Possible.  儘量隔離依賴               

                                                                 -- from <<Test-Driving JavaScript Applications >>
      等以上這些都表達不要依賴數據庫等外部資源.  筆者在某中型公司框架中還看到誤人子弟的單元測試示例,鏈接了數據庫, 那已經不是單元測試, 已變爲集成測試.

  三.  Arrange-act-assert 結構

     良好的結構是好的開端

        四. 一些原則

         咱們原則有 「測試驅動模塊化設計」

      「SOLID原則」

       代碼可測試性原則:

避免複雜private方法
避免final方法
避免static方法
使用new時當心
避免邏輯在構造函數中
避免Singleton
優先組合而不繼承
包裝外部組件

總結

      理解測試, 是咱們須要敏捷軟件開發過程基礎. 作爲一個軟件開發工程師你須要比任何一我的都關注質量. 你不能總想着有人幫你測試. 相反是你對你的程序複雜找出BUG修正在正在交給其餘人前. 緣由很簡單, 開發軟件總有BUG, 修復BUG是昂貴的. 上升高度, 你的產出影響了其餘人, 如何提升你的影響力.

---

今天先到這兒，但願對您技術領導力， 企業管理，物聯網,  系統架構設計與評估，團隊管理, 項目管理, 產品管理,團隊建設 有參考做用 , 您可能感興趣的文章:
2017-2018年Scrum狀態調查報告
2016年測試狀態調查
2017年IT行業測試調查報告
項目管理－習慣發生範圍變動
前端性能覈對表Checklist-2018
大型電商互聯網性能優化案例
國際化環境下系統架構演化
微服務架構設計
視頻直播平臺的系統架構演化
微服務與Docker介紹
Docker與CI持續集成/CD
互聯網電商購物車架構演變案例
互聯網業務場景下消息隊列架構
互聯網高效研發團隊管理演進之一
消息系統架構設計演進
互聯網電商搜索架構演化之一
企業信息化與軟件工程的迷思
企業項目化管理介紹
軟件項目成功之要素
人際溝通風格介紹一
精益IT組織與分享式領導
學習型組織與企業
企業創新文化與等級觀念
組織目標與我的目標
初創公司人才招聘與管理
人才公司環境與企業文化
企業文化、團隊文化與知識共享
高效能的團隊建設
項目管理溝通計劃
構建高效的研發與自動化運維
某大型電商雲平臺實踐
互聯網數據庫架構設計思路
IT基礎架構規劃方案一(網絡系統規劃)
餐飲行業解決方案之客戶分析流程
餐飲行業解決方案之採購戰略制定與實施流程
餐飲行業解決方案之業務設計流程
供應鏈需求調研CheckList
企業應用之性能實時度量系統演變

若有想了解更多軟件設計與架構, 系統IT,企業信息化, 團隊管理 資訊，請關注個人微信訂閱號：

做者：Petter Liu
出處：http://www.cnblogs.com/wintersun/ 本文版權歸做者和博客園共有，歡迎轉載，但未經做者贊成必須保留此段聲明，且在文章頁面明顯位置給出原文鏈接，不然保留追究法律責任的權利。 該文章也同時發佈在個人獨立博客中-Petter Liu Blog。