創(chuàng)建單元測試是一件乏味的事情。代碼本身是重復(fù)的，通常需要與被測代碼一樣多的努力，除此之外，單元測試代碼本身需要修復(fù)和調(diào)試。幸運的是，單元測試非常適合自動化，而工具指導(dǎo)可以極大地簡化測試創(chuàng)建，減少調(diào)試和修復(fù)的數(shù)量，并收集結(jié)果和指標以提供項目分析。


超越IDE


例如，許多IDE為Junit提供了單元測試創(chuàng)建向?qū)В珱]有提供完成該過程的“內(nèi)容”。斷言需要手動定義，如果使用模擬框架，則需要大量手動編碼。這就是通過在開發(fā)人員的IDE中提供實時、上下文感知的幫助來引導(dǎo)測試創(chuàng)建的地方。通過引導(dǎo)式測試創(chuàng)建，可以快速高效地完成簡單框架單元測試中缺少的“內(nèi)容”，因為測試助手會執(zhí)行以下操作：


創(chuàng)建測試框架，實例化對象，并配置適當?shù)哪M對象和方法。


執(zhí)行測試自動化執(zhí)行的運行時分析，以突出顯示測試期間更改的對象值，并建議驗證這些值的斷言。


標識應(yīng)該模擬的方法調(diào)用，以便更好地隔離測試中的代碼。


檢測已創(chuàng)建但在測試完成后未釋放的系統(tǒng)資源，這可能會創(chuàng)建不穩(wěn)定的測試環(huán)境。


收集代碼覆蓋率和其他指標。


減少模擬的復(fù)雜性


單元測試意味著被測試對象的隔離，如果存在許多依賴項，則需要相當多的工作。即使使用Mockito或PowerMock等模擬框架，仍然需要大量的手動編碼。使用自動測試助手工具，你可以檢測依賴項并自動填寫框架所需的詳細信息。該工具本身分析測試中的代碼，自動檢測依賴項，并向開發(fā)人員提出建議。


通過自動化減少測試套件維護


測試套件的維護與測試創(chuàng)建所需的許多工作重疊，例如創(chuàng)建新測試、修改測試以適應(yīng)底層邏輯、模擬依賴項、測試執(zhí)行和驗證。在測試維護期間從自動化工具獲得幫助與在創(chuàng)建期間一樣有價值，因為它提供了測試執(zhí)行期間收集的運行時分析結(jié)果的更新反饋。例如，在運行時檢測到測試對象中的新依賴項，該工具會提示開發(fā)人員如何處理它。在這個階段，同樣重要的是確保斷言仍然有效。助手提供的建議可以檢測代碼中的更改，并更新斷言以反映新的業(yè)務(wù)邏輯。


最大限度地利用現(xiàn)有工具


已經(jīng)進行單元測試的Java開發(fā)人員可能會使用Junit，并且可能會為他們的項目使用斷言框架，例如Mockito或PowerMock。測試自動化工具需要利用這些現(xiàn)有工具，因為替換單元測試中的現(xiàn)有投資將消除任何成本和時間效益。與這些現(xiàn)有工具無縫集成至關(guān)重要。


結(jié)論


單元測試有明顯的好處，盡管大多數(shù)開發(fā)團隊都意識到了這一點，但許多開發(fā)團隊都被創(chuàng)建和維護測試的工作所阻礙。引導(dǎo)式單元測試創(chuàng)建技術(shù)可以輕松地消除這些障礙，并自動化單元測試的日常方面，包括創(chuàng)建、隔離、模擬和維護。為了加快技術(shù)的采用，引導(dǎo)式測試創(chuàng)建工具利用了開發(fā)團隊在測試和模擬框架方面的現(xiàn)有投資，并在將質(zhì)量帶回產(chǎn)品的同時，將時間回饋給開發(fā)人員。