分布式系統中的CAP理論，面試必問，你理解了嘛？
對于剛剛接觸分布式系統的小伙伴們來說，一提起分布式系統，就感覺高大上，深不可測。而且看了很多書和視頻還是一臉懵逼。這篇文章主要使用大白話的方式，帶你理解一下分布式系統
Rust中的測試函數是用來驗證非測試代碼是否是按照期望的方式運行的, 測試函數體通常需要執行三種操作:1.設置任何所需的數據或狀態;2.運行需要測試的代碼;3.斷言其結果是我們所期望的。本篇文章主要探討了Rust自動化測試的幾種常見場景。
在Rust項目工程中, 可以對任意函數進行自動化測試, 前提是需要在被測試函數上面加上#[test]注解, 然后運行cargo test命令進行函數自動化測試, Rust會查找所有被#[test]注解的函數并自動進行測試。
先看下面一段代碼:
#[test]fn add_calc() { let result = 1 + 2; assert_eq!(result, 3);}在上面的代碼中, 我實現了一個加法計算的函數: add_calc(), 將加法結果保存到不可變變量result中, 并使用了assert_eq!宏來斷言1+2的結果, assert!宏由標準庫提供, 在希望確保測試過程中一些條件為true時非常有用。在函數上方加上了#[test]注解, 表示該函數將執行自動化測試, 運行: cargo test看下結果:
圖片
從測試結果中, 可以看到test add_calc ... ok 這行, 表示該函數測試通過了。
現在我修改下斷言的結果, 將代碼修改為:
#[test]fn add_calc() { let result = 1 + 2; assert_eq!(result, 4);}再次運行cargo test命令, 返回結果如下:
圖片
可以看到, 計算的結果是3, 但斷言相等的條件是等于4, 因此函數執行失敗, add_calc()函數自動化測試不通過。
接下來我們再加入一個函數, 看看在具有多個函數的前提下, 同時具備成功和失敗的情況, 代碼如下:
#[test]fn add_calc() { let result = 1 + 2; assert_eq!(result, 3);}#[test]fn another_method() { panic!("執行失敗,拋出一個異常!")}在上面的代碼中, 增加了一個名為another_method()的函數, 該函數直接使用panic!拋出一個異常, 直接扮演了函數執行失敗的角色, 而上面的add_calc()函數我講assert_eq!宏修改正確, 將扮演執行成功的角色, 使用cargo test命令看下結果:
圖片
可以看到, add_calc()函數測試沒問題, 后面用綠色ok表示, 而another_method()函數執行失敗, 使用紅色的FAILED標記。
在上面的案例中, 我使用了assert_eq!宏來斷言結果, 同樣, 也可以向宏傳遞一個可選的失敗信息參數, 可以在測試失敗時將自定義的失敗信息一并打印出來, 使用自定義信息有個好處, 當測試失敗時, 能更好的理解代碼到底出了什么問題, 看一段下面的代碼:
pub fn make_string(name: &str) -> String { format!("Hello,{}!", name)}#[test]fn is_contain_name() { let result = make_string("cargo"); assert!(result.contains("cargo"));}在這段代碼中, 定義了一個函數make_string, 該函數接收一個字符串參數, 并在函數內部通過format!宏格式化字符串后返回, 在函數is_contain_name()中, 傳入一個字符串"cargo", assert!會判斷make_string()函數返回的字符串中是否會包含"cargo"字符串,如果包含就是成功的,否則就失敗, 這里我們能預言結果應該是成功的, 測試一下看看:
圖片
結果跟我們預想的一樣, 現在再加入一些更詳細的變化信息看看, 代碼如下:
pub fn make_string(name: &str) -> String { format!("Hello,{}!", name)}#[test]fn is_contain_name() { let result = make_string("rustup"); assert!(result.contains("cargo"), "make_string中不包含該字符串,值為:`{}`", result);}我在assert!宏中加入了變量打印, 假如make_string()函數沒有返回預期的結果, 那結果到底是什么,這里我們將能看到失敗原因, 測試結果如下:
圖片
從結果可以看到, 函數的確測試失敗了, 但我們看到了關鍵信息, 失敗的原因是因為make_string()函數返回的字符串內容為:Hello,rustup!,這個結果與斷言中的result.contains("cargo")結果是不同的, “Hello,rustup!”字符串中并不包含"cargo"字符串,所以函數測試失敗。
除了使用斷言宏之外, Rust還提供了一個should_panic用來檢測程序中的panic,并且提供了一個名為expected的參數用來自定義消息,看一段下面的代碼:
pub fn number_calc(value: i32) -> i32 { let ret_value = 40; if value < 0 { panic!("值必須大于0,傳參的值為:{}", value) } return ret_value}#[test]#[should_panic(expected = "傳參不能小于0")]fn is_contain_name() { let result = number_calc(-1);}在number_calc()函數中, 如果判斷參數傳入的值小于0, 會拋出一個panic, 為了監視是什么原因導致, 在函數is_contain_name()上面使用should_panic進行監控, 并使用expected參數指定自定義消息, 如果遇到傳入的參數小于0, 將觸發該消息打印, 使用cargo test運行一下看看結果:
圖片
從結果可以看到, 的確檢測到了panic產生, panic打印了本身的消息, 最后一行shoud_panic也觸發了消息, 并打印出失敗的原因。
先看一段下面的代碼:
pub fn number_calc(value: i32) -> i32 { let ret_value = 40; if value < 0 { return 30 } return ret_value}#[test]fn is_contain_name() -> Result<(), String>{ if number_calc(2) == 40 { OK(()) }else{ Err(String::from("結果不等于40,請檢查原因!")) }}在上面的代碼中, is_contain_name()函數的返回類型現在變為:Result<(), String>, 在函數體中, 不同于調用assert_eq!,現在如果測試通過,將返回Ok(()), 在測試失敗時, 返回帶有String的Err錯誤。現在傳入參數為2, 將顯示正常的結果:
圖片
現在我們再傳入一個小于0的負值看看,結果如下:
圖片
可以看到, 如果使用Result<(), String>接收結果, 當出來錯誤時, 將返回一個Error,并打印對應的自定義消息。
在本篇文章中, 我們使用#[test]注解完成了對指定函數的自動化測試, 使用assert!宏對錯誤進行斷言, 在斷言中自定義錯誤顯示消息用于查看更詳細的錯誤原因。使用了should_panic對panci錯誤進行了監控, 最后使用Result<T, E>替代斷言分別完成了代碼測試和自定義錯誤消息打印, 在以后的實際應用中, 可能還會有一些組合測試的場景出現, 到時候再具體問題具體分析。
本文鏈接：http://www.www897cc.com/showinfo-26-34601-0.html我們一起聊聊異地多活之業務定制型異地多活架構
聲明：本網頁內容旨在傳播知識，若有侵權等問題請及時與本網聯系，我們將在第一時間刪除處理。郵件：2376512515@qq.com
上一篇： 聊聊 Calico BGP容器網絡實踐
Copyright ? 2016-2023 天津谷騏科技有限公司 版權所有 sitemap.xml
違法及侵權請聯系：2376512515@qq.com 津ICP備18001702號
津公網安備 12010102000574號