使用服務虛擬化改善開發者協做

對於一個開發人員來講，沒有什麼比不斷地從頭開始重建事物更使人沮喪的了。面向對象設計的一個核心原則是可以爲每一項工做建立一個對象或一個可參考的點，因此你永遠沒必要重複本身。

儘管有這個核心原則，但當涉及到模擬時，開發人員常常發現本身在不斷地重複一樣的過程。

但爲何呢？當開發人員在編寫應用程序代碼時，他們常常與相同的外部API進行通訊，並以不一樣的方式對同一服務進行相同的調用。傳統的mock的問題在於，它們是在代碼層面編寫的，並且它們是專門爲與正在開發的功能一塊兒工做而設計的。所以，每次須要行使該功能時，都必須建立一個新的mock。

在使用傳統的mock框架時，很難共享已經建立的mock，不只由於可能不知道它們存在於代碼庫中的什麼位置，並且也很難理解一個特定的mock是與哪一個需求綁定的。所以，最終發生的狀況是，個別團隊成員常常建立與坐在他們旁邊的人相同的mock。這簡直是在浪費開發者的精力和時間。

個人mock在哪裏？

一旦開發人員建立了一個mock，協做也變得頗有挑戰性。由於沒有一個神奇的儀表板存在，你能夠在那裏發佈關於已經建立的模擬的通知，讓團隊瞭解狀況。

我最近有一家醫療機構的客戶，該機構將模擬做爲一種常見的開發實踐，他們有一個服務提供商老是離線，這使得它成爲模擬的常見目標。所以，各個開發人員都在本身的代碼庫中爲它作了一個模擬界面。它們都略有不一樣，但達到了一樣的目的。當我與這些開發者溝通時，我發現大約有20個相同的mock存在。這甚至也讓他們感到驚訝。當被問及重複工做的問題時，他們的回答，倒是語氣沉穩，並不徹底出乎意料。「咱們太忙了，沒時間溝通。」

聽起來很熟悉？（我但願我在這裏有一個實際統計的數據能讓你感受好一些）

但模擬是必要的，正如任何開發人員或測試人員會解釋的那樣，由於你在進行開發時須要有能力將本身與其餘世界脫鉤。模擬是一種用可保護的環境來包圍你的應用程序的方法——但這個解決方案有其固有的挑戰，包括：

• 從頭開始重建每個mock是很乏味的，並且浪費時間
• 試圖發現現有的模擬是困難的
• Mocks的存在是沒有目的的——它們不與特定的API掛鉤，也不能重複使用
• 你們雖然須要合做，但忙於溝通，無暇顧及

進入：服務虛擬化。經過這種測試實踐，你能夠簡化模擬的過程，並建立一個可重用的虛擬服務庫，共享核心功能。因此你能夠中止反覆建立虛擬服務。

使用服務虛擬化

咱們來看一個例子。比方說，有一個現有的服務，經過接收一個傳入的帳號，爲這我的提供身份信息，並返回一個響應，同時須要開發一個新的虛擬服務，在這個服務中，根據帳號，返回財務細節。

經過服務虛擬化，在建立新的虛擬服務時，能夠利用原有服務的不少內容。惟一能將兩個服務分開的是模式和數據。而隨着企業創建愈來愈多的虛擬服務，他們能夠重用的工件庫也會變得更大。這就解決了最初不得不反覆建立相同虛擬服務的挑戰。

共享虛擬服務

與mock不一樣，虛擬服務具備高度的可共享性，內部模塊也能夠重複使用。虛擬服務或pva文件能夠以XML的形式存儲，而且能夠很容易地檢查到源碼控制中。若是服務模擬特定API的特定功能，你能夠在源碼控制中搜索工件，或者更容易在共享虛擬化服務器上搜索。隨着團隊對服務虛擬化使用的增加，他們能夠利用現有的服務器共享功能，直接將本身的桌面鏈接到服務器上搜索本身須要的工件，直接拉到本身的桌面上，並當即開始使用。這就解決了發現已經建立的虛擬服務並當即訪問的難題。

捆綁虛擬服務

Parasoft Virtualize還提供了一個從常見的虛擬化用例創建的私有和公共構件市場。這使你能夠快速啓動並在整個組織中創建一個內部知識庫，以簡化將來虛擬服務的建立。當你開始利用虛擬服務時，你能夠輕鬆地將該虛擬服務與其初始 API 命名慣例或經過描述或標記聯繫在一塊兒。

而後，你的開發夥伴能夠直接在 Web 瀏覽器中搜索爲他們想要模擬的 API 所建立的任何虛擬資產，並準確地看到已建立的虛擬資產，並當即部署到他們的桌面：

這就解決了將虛擬服務與其特定的API和要求聯繫在一塊兒的挑戰。

與虛擬服務協做

最後，鑑於以上全部的解決方案，你的團隊能夠創建一個可持續的工做流程，讓開發人員和測試人員在乎識到須要模擬時有選擇。他們沒必要花時間來回奔波，而是能夠在Parasoft生態系統中查詢適合他們特定需求的mock，若是存在一個，他們能夠當即得到它。若是沒有，他們能夠建立一個虛擬服務，團隊能夠重複使用，而且將來任何須要它的人均可以發現。這就解決了相關協做的難題。

那麼如今該怎麼辦呢？

開始與你的虛擬基礎設施進行協做，你能夠經過開始下載來走出第一步——資產能夠檢查到源控制，推廣到共享團隊服務器，並上傳到你團隊的私人市場。祝你虛擬化愉快！