為您的智能合約編寫單元測試非常重要，就像為任何開發(fā)項目編寫代碼一樣。然而，基于區(qū)塊鏈的解決方案中的單裝置測試常常被低估和忽視。去年，我對大部分為以太坊以及Neo、Eos、Tron和比特幣區(qū)塊鏈撰寫的智能合約進行了200多次審計。根據(jù)我的觀察，這些項目中有將近一半沒有編寫裝置測試。這種監(jiān)督常常導(dǎo)致合同執(zhí)行情況不佳，以及審計過程中發(fā)現(xiàn)的各種安全問題。

?

必備的測試

每個智能合約都有一些共同的部分，比如構(gòu)造函數(shù)、總供應(yīng)、用于來回傳輸?shù)暮瘮?shù)、用于審批的函數(shù)，有時還有用于燃燒額外代幣的函數(shù)。因此，檢查您的智能合約是否正確初始化所有參數(shù)，以及當您溢出總供應(yīng)或其他裝置值時是否能及時返回，都是非常重要的。您還需要檢查修飾符和正確的權(quán)限使用。

在這里，我們將以以太坊為例，但這也適用于其他平臺，因為合約往往具有相同的結(jié)構(gòu)。首先，讓我們測試適當?shù)拇鷰懦跏蓟蛯δ硞€地址的正確傳輸。

正確初始化的測試很簡單。您只需要創(chuàng)建一個示例合約并檢查所有必須初始化的值的正確性即可。

檢查傳遞函數(shù)是非常重要的，因為可能會有一些問題會導(dǎo)致不正確的傳遞。您必須確保接收方和發(fā)送方的平衡，試圖得到恢復(fù)以防被錯誤的函數(shù)參數(shù)所影響，例如，發(fā)送數(shù)量超過發(fā)送方的平衡，合同地址或無效的地址進行了發(fā)送等等情況都有可能發(fā)生。最后， 您必須檢查從傳輸事件獲得正確的日志。

transferFrom函數(shù)非常類似于transfer，但是這里您還需要測試spender是否有足夠經(jīng)過批準的余額來發(fā)送。以下是在支出比所需資金少的情況下進行的測試。

approve函數(shù)是ERC20標準中最簡單的函數(shù)。不需要檢查零地址，只要檢查津貼數(shù)組是否正確填充就足夠了。另外，如果您沒有增加審批或減少審批功能，approve將覆蓋所有先前的值。因此，我們建議使用這些函數(shù)來防止不必要的覆蓋。當然，檢查從審批事件中獲得正確日志是很重要的。

大多數(shù)智能合約都包含了一個函數(shù)，用于燃燒主銷售后遺留的代幣。它們中的許多都有一個特殊的代幣持有者帳戶，有時是所有者帳戶。因此，對于燃燒未售出的代幣，最好的解決方案是：獲取持有者地址上的代幣數(shù)量，然后從總供應(yīng)中減去這個數(shù)量，并將代幣數(shù)量設(shè)置為零。這將確保您不會燒掉所有的代幣，因此在白紙上列出代幣燃燒策略是很重要的。

結(jié)論

在將智能合約部署到主網(wǎng)絡(luò)之前，測試它是非常重要的，以防止將來出現(xiàn)問題。當您編寫了裝置測試時，它們將保證您的白皮書和智能合約之間不會有任何差異，并且您的智能合約不會被調(diào)用功能所攻擊。

一段時間以來，我聽到的最佳編程訪談引語是：“在裝置測試完成之前，代碼不會先完成。——@brianrivard

這不僅僅是只關(guān)于智能合約，你需要為你的所有應(yīng)用和代碼進行裝置測試，因為它向你展示了你的應(yīng)用可能如何失敗的所有方式。