⨠ Hi, I am RiceBen 🦀

「單元測試的藝術」讀書會 - 用 stubs 解除相依 (The Art of Unit Testing, 3e - Breaking dependencies with stubs) 閱讀筆記。 解除相依性 在測試 SUT ( stand for system under test)，可能會遇到一些外部的相依，讓測試變得不可靠而且脆弱。這個時候我們就需要想辦法跟這些我們無法控制的元件/系統或是服務解除相依，讓這些東西可以在我們的掌控之下。 這邊依據 SUT 跟該服務的互動方式區分為 Outgoing dependency 和 Incoming dependency --- title: Outgoing dependency --- flowchart LR UST{{"Unit of work"}} test((Test)) Dep{{"Dependency"}} test--Entry point-->UST UST--Exit point-->Dep 這個類型的相依通常是 API 通知、打 webhook、寫 log 或是存資料到 DB。這些會帶有 通知、呼叫 或是 發送 的行為通常就是 outgoing 相依的特徵，這些行為都有把流程（或資料） 帶出 這個 unit of work 因此每一個都是一個 exit point。 ...

前言 會想自己弄一個 Github Action 除了自己有需求目前找不到既有的服務可以滿足之外，就是很想自己也動手玩玩看這個便利的工具。這個需求的產生主要是因為近年在跟團隊合作時，有發現要讓團隊成員養成保持專案的分支整潔的這件事情上面實在有點困難，主因是開發常常多頭進行之外，就是沒有一個時間是可以讓大家喘口氣好好整理目前的 Codebase，既然連 Code 都沒時間整理了，專案的分支就更不用講了。只是這樣長久下來實在有太多無意義的分支殘留，在搜尋時與管理時會有些麻煩，因此若有一個小幫手能夠自動自發的幫忙清理分支那就好很多了。 起步走 想直接看最終成品的可以到這邊看最後完成的樣子跟使用方式。但要先提醒急著用的人，這個 action 會把符合條件的 branch 砍掉，基本上屬於不可逆操作，所以使用說明需要先看仔細。 目前 Github action 主流是用 nodejs 開發，因為相關的 ecosystem 還滿完整豐富的開發起來還滿快的，所以這個指南就用 nodejs 來做簡易教學。會順手使用 volta 和本機端測試 Github action 的好用工具 act。 volta 的使用可以參考這篇文章。 初始設定 1 mkdir {your-project-path} && cd {your-project-path} 設定專案初始值 專案使用 typescript 但因為只有開發階段需要所以只須裝在開發階段，另外再安裝一些開發階段才會需要的套件。 1 2 npm init npm install --save-dev typescript @types/node @vercel/ncc @types/jest jest ts-jest gts 安裝後可以用以下指令測試 typescript 是否安裝成功 npx tsc -v 安裝完上述開發環境的套件後有一些套件需要初始化設定，像是 typescript、gts 跟 jest。 初始化 typescript。裡面有很多可以設定的參數，可以參考這裡。而初始化 jest 可以參考這裡，另外 gts 的相關資訊能在這邊看看。 在 jest 的設定方面有一個小撇步，那就是不要使用 typescript，讓它用一般的 javascript 檔案格式就好，不然編譯的時候預設會往 tsconfig.json 裡的 rootDir 位置去找 jest.config.ts ，該位置找不到檔案的話就會編譯失敗。 ...

為什麼有這種需求 目前我使用容器的主力是 Podman 不過有些跟容器整合的工具（e.g. AWS SAM CLI, act）是只支援 Docker 這套工具的，對於 Podman 的支援官方是從不保證能通。有礙於這類工具實在對於生產力很有幫助，所以開始研究兩者並存的可能性。不過因為 Docker Desktop 因為已經不是免費了，所以目標就是只安裝 docker engine，然後用 docker client cli 來使用 service 。 前置條件 這篇是以 Podman 已經安裝好的情形下來展示，如何接續安裝 Docker engine。 確認 wsl 版本是 version 2 wsl --set-default-version 2 更新 wsl 避免踩到舊版的坑 wsl --update 安裝指定版本號，這邊直接指定最新的 Ubuntu 版本 wsl --install -d Ubuntu-22.04 停止該虛擬機器，因為我們要準備把虛擬硬碟從預設路徑搬移出去 wsl -t Ubuntu-22.04 匯出 wsl --export Ubuntu-22.04 {new path}\Ubuntu-22.04.tar 解除註冊 wsl --unregister Ubuntu-22.04 在新的地方重新註冊虛擬機 wsl --import Ubuntu-22.04 {new path}\Ubuntu-22.04 {new path}\Ubuntu-22.04.tar 進入虛擬機器裡 wsl -d Ubuntu-220.4 --user {your_user_name} ...

在撰寫一些自動化流程的時候覺得 Makefile 的寫法不習慣，或是環境的支援太薄弱嘛？覺得 Makefile 的寫法太過古老，每次撰寫都像是在寫古文嘛？給 Taskfile 一個機會吧 有別於 Makefile 的地方 基本上 Taskfile 跟 Makefile 都是為了一些自動化流程需求所發展出來的工具，既然目的相同又謂何要換呢？ 它只相依一個 library 檔案，而且檔案只有約 9MB YAML 語法以及一些內建語法的支援 special variables environment variables Makefile 在 windows 太老舊 Windows 版本在 3.81 Linux 版本在 4.4 方便整合在現在流行的 CI 方式，包括 Github Action Github Actions integrate Windows 上的安裝 若是有 Chocolatey 或是 Scoop 的話有很方便的安裝指令 1 choco install go-task 1 scoop install main/task 當然 winget 也是可以 1 winget install Task.Task 若上述的工具都沒有，官網有詳細介紹各種安裝方式。 使用不同版本 (Taskfile versions) 標示 Taskfile 所使用的版本可以使用特定版本才開放的功能。可以從這邊確認一下新的版本有提供什麼不同的功能。 變數 (Variables) 在介紹變數前先參考這份簡易的範例。 ...

TL;DR 模型的選擇並非絕對，你也可以用其中一種模型用到底，只是在使用上就不會這麼順暢。你可以在迭代快速的 Web 服務使用略為繁瑣的 Git Flow 也可以在需要同時支援多個版本服務的專案上使用 GitHub Flow 只是你會發現你會越用越受到流程的限制，最後要不就是放棄既有流程，不然就弄出一個屬於自己的流程（但我覺得這不見得是壞事，只是需要多一點團隊教育成本），在選用分支模型前還要先看看你們服務的上版節奏以及是否需要同時支援不同版本的情況。 Why Branching Model Matter 通常會需要考量用什麼分支模型基本上都是有協作的需求，開發的人不是只有一到兩個人，才會需要有一個大家都知道的開分支後合併的方式，才不會亂成一鍋粥。也可以在 release 時清楚的知道要從那一個 commit 出一個 artifact。 分支模型不只跟開發團隊如何協作有關，也關乎到團隊是如何做發布。近年很多在討論 DevOps 相關的場合裡滿多都在討論工具要怎麼使用，也有滿多篇幅討論怎麼做 CI/CD ，甚至是部屬時要用什麼樣的策略，金絲雀部屬、藍綠部屬等。不過卻滿少連帶討論到團隊的分支模型是怎麼選擇的。因為模型的選擇也跟團隊的部屬節奏有關連，若發布新版本的節奏很快的話（一週內就一個甚至多個新的版本推上去）甚至可以不需要 hotfix branch 的存在，但若是節奏很不穩定的話或是偏長（數週甚至數月一個版本）那 hotfix 就需要特別考量在分支模型裡面。以下就以常見的分支模型來分別探討他們適合用在哪些情境。 GIT FLOW ref: https://nvie.com/posts/a-successful-git-branching-model/ 這算是很早期提出來的分支模型。分支數量算是最多的一種，所以線圖也算是相對不需要做什麼動作就顯的複雜的一種。雖然這個模型相對麻煩，操作也相對繁瑣，但是因為發展最久大家也算是相對熟悉的模式，甚至還有 CLI 工具與 GUI 工具支援這個模型的操作。 這個模式還滿適合發布頻率較為穩定的服務，也能很好的符合稽查相關的需求，另外就是有特別切出 release branch 的關係，需要同時支援多個版版時，會比較容易一些。 分支是常見的模型中最多的，因此操作步驟相對最複雜，也滿吃團隊成員對於 git 的操作（當然是有工具可以減輕負擔跟知識要求，但出問題時的修復比較麻煩）。但需要注意的是，當同時開發的 feature branch 變多的時候管理會顯的相對不容易。 GITHUB FLOW ref: https://github.com/skills/release-based-workflow 這個模式基本上是以 branch 為主的極簡化版本，捨去了 release branch, hotfix branch 和只為了發布時下 tag 使用的 master branch。保留了 main branch 同時兼具開發時為基底的需求，同時也是 release 時下 tag 的目標 branch。同樣在開發功能時會切出一個 feature branch 做管理。 ...

Times Before Volta 在 volta 問世之前我想管理 Node.js 版本的工具這個選項大概就是 nvm 了。不過 nvm 他是單純的管理 node 版本，而且他不會自動切換版本，你需要自己手動執行（也是可以寫 script 達成自動切換，只是這樣新電腦重新設定環境時比較麻煩）但這樣就太不懶人了，最好就是可以切換資料夾後他可以自己認得現在該用什麼，不過當時市面上沒有比較好的替代方案，所以也是只能將就的用下去。 Why You Need Volta volta 其中一個好用的點在於你的專案 volta pin 了特定版本的 node 後，只要切換資換資料夾 node 版本也會順便幫你一起切換。 若切換到的專案底下所指明的 node 版本並未安裝的話， volta 會幫您安裝好在 package.json 鎖定的版本與相依的套件（node, npm, etc…）。這樣就不需要擔心下載下來的專案是否有包含你沒有安裝的工具，因為這些 volta 都會自動幫你處理好。 這樣做還有另外一個好處，若團隊都採用 volta 的話，就不需要擔心成員的環境是否跟你不一樣，因為 volta 會幫你處理好這一塊，讓你們使用的工具都維持在同一個版本。 Install Volta 官方有提供無腦安裝方式，不論是 Unix 還是 Windows 都很簡單。 在 Windows 上值得一提的是， volta 其實也可以用 scoop 裝起來！ 執行： 1 scoop install volta 註：scoop 的安裝方式可以參考這裡 Developer Mode On Before Use It 在 Windows 環境上使用 volta 請記得先把開發者模式打開，主要是他會用到軟連結(symlink)。開啟方式可以參考官方說明 ...

前言 Git 裡面有多強大但是使用時機沒這麼廣泛的功能，submodule (Git - Submodules) 就是其中一個。目前大多數的專案應該不會用到這個東西吧，最近也是因為部落格布景主題要換（又想換了 XD）所以才又重新再回憶這段指令。 What is submodule? 在軟體開發的過程中，有一些發展比較古老的大型專案，為了要將專案作更細緻的管理會將大型專案切分成數個小型專案，然後這些專案會交給不同的開發團對來開發，這樣做的話就可以讓一個 repo 瘦身，也可以讓多個團隊同時開發一個大型專案。而這些 submodule 又可以擁有各自的版控，但又不會跟主要的專案脫勾，在解耦的同時保有一定的連結。 還有另外一種使用 submodule 的情境，就是你的專案需要把別人的東西納入，而這依賴還不能透過套件管理程式 (比較常見的大概會是 Web 類型的專案，引入別人的樣式或是 template)，需要將原始碼納入專案中，這時該怎麼處理？另外，假設對方還會更新這個東西的話，單純只把對方的原始碼 Copy 下來就顯的不切實際一點了。我們可以怎麼做呢？這個時候 submodule 就會是很好的解決方案。 新增一個 submodule 方式滿簡潔的，基本語法如下： 1 git submodule add <remote repository> <local path> 實際範例： 這邊假設你目前的位置就是主 repo 的根目錄。然後不需要先幫他建立空的目錄。 1 git submodule add https://github.com/chipzoller/hugo-clarity.git themes\hugo-clarity 1 2 3 4 5 6 7 8 9 🕙 {your prompt} ➜ git submodule add https://github.com/chipzoller/hugo-clarity.git themes/hugo-clarity Cloning into 'D:/Repos/Tutorials/ElsaWorkflowTutorial/themes/hugo-clarity'... remote: Enumerating objects: 5085, done. remote: Counting objects: 100% (2/2), done. remote: Compressing objects: 100% (2/2), done. Receiving objects: 100% (5085/5085), 6.10 MiB | 12.88 MiB/s, done. Resolving deltas: 100% (3126/3126), done. warning: in the working copy of '.gitmodules', LF will be replaced by CRLF the next time Git touches it 從這邊的資訊可以發現所謂的 submodule add 就是會把別人的原始碼給抓下來，不過入版控的內容你會發現他其實只記錄了那個 repo 的 sha1。可以 diff 一下你會發現他的獨特之處 ...

前言 你有排程相關的需求嗎? 需要定期呼叫指定的方法來做事嗎? 相信大家多多少少都有接過類似的需求，不過除了使用 Windows 的排程來做或是使用 cron job 這些傳統工具來做到之外你還有更現代的選擇 - Hangfire。 內文 其實 .NET solution 的排程選擇不只 Hangfire 還有老牌的 Quartz.NET 也是非常好的選擇。單純以排程作業來說 Quartz 可以做到的控制是比 Hangfire 還要來的更細緻，不過 Hangfire 就優勢來說大概就是比較沒有歷史包袱，管理介面也是本身內建，不像 Quartz 是需要另外找第三方來幫助 (ex. GitHub - CrystalQuartz)。 好啦….其實兩個都很好我只是雞蛋裡挑骨頭…只是最近有用到 Hangfire 所以就用這個來練習排程吧～ Initialize your project for Hangfire Hangfire 最吸引人的地方除了他學習成本較 Quartz.NET 低，另外就是他自帶漂亮 Dashboard 而且設定還很容易。想要套用 Dashboard 的話先引用套件 1 dotnet add package Hangfire.AspNetCore 這個套件會相依 Hangfire.Core 所以可以先裝這個就好，然後在 Configure 設定區塊裡補上以下這段 1 2 3 4 5 6 7 8 9 10 11 12 13 public void Configure(IApplicationBuilder app, IWebHostEnvironment env) { //... app.UseEndpoints(endpoints => { endpoints.MapHangfireDashboard( new DashboardOptions { StatsPollingInterval = 3600000 }); } //... } StatsPollingInterval 這個參數的預設值是 2000 它的單位是毫秒，也就是 2秒它就會去背景檢查 Job 執行的狀態，這個數值在測試環境基本上不用太擔心什麼，不過若是正式環境的話建議要調整，不然會讓背後儲存 Job 的位置壓力很大 (若是存在關聯式資料庫的話就更要小心了)。 ...

前言 之前主要是因為 Docker Desktop 開始收費 (Docker Subscription Service Agreement | Docker) (Docker CLI 依舊免費 ) 但因為免費條件有點嚴苛，而且通常都是在為了公事使用，為了避免不小心讓公司有意外支出，就開始萌生有沒有更安全的替代解決方案。另外就是 WSL 2 已經很成熟了。 Podman 跟 Docker 目前 (2022/03) 最大的差異應該就是兩者架構不同，Docker 是傳統的 Client-Server 架構它由一個 daemon 來操作所有由 docker cli 產生的 container ，而 Podman 則是不需要 daemon 。這樣可以預防 single point of failure 不會像 docker daemon 一死底下的 container 跟著一起殉情。而多數人在講的 podman 可以 rootless 的優勢則在 docker engine 升級到 20.10 後就也支援 rootless 了，來源在此。 有人針對雙方架構畫了一個很好的圖示 圖片來源: podman_introduction 起步走 =========== ↓↓↓ 25/07/2022 Update ↓↓↓ ============== ...

2023/2/6 Updated: 調整文章順序，強調 scoop 章節，更新常用工具。 2023/10/10 Update: 調整文章描述，更新常用工具。 全新 Windows 環境上基本開發設定 會興起寫這個的念頭實在是因為這些年頭也遇到不少次重灌工作機的時候，但是安裝的工具實在太多，沒有一個 script 或是筆記實在會忘記這些設定要怎麼處理，每次重新回憶一遍也是很浪費生命。這經歷過好些年後 Windows 環境上出現不少方便的工具，恰好近期我又需要重灌工作機了，用這個機會紀錄一下，順便推廣一下我覺得超好用的工具。 先放上寫好的 script: 設定好 scoop 的安裝路徑(環境變數) 這個設定若你不太在乎硬碟空間的話是可以跳過啦，不過 scoop 軟體預設都會安裝在系統槽 (也就是 C槽)，就看你個人使用習慣了。我個人是習慣避開系統槽。 這邊先設定 scoop 的安裝路徑，同時這也會是用 scoop 安裝的應用程式的根路徑。預設會是 scoop 位置下的 app 資料夾裡。 $env:SCOOP='D:\Applications\Scoop' [Environment]::SetEnvironmentVariable('SCOOP', $env:SCOOP, 'User') 接下來你也可以另外設定下載下來的應用的暫存位置。預設會是在 scoop 安裝位置下的 cache 資料夾裡。 $env:SCOOP_CACHE='D:\ScoopCache' [Environment]::SetEnvironmentVariable('SCOOP_CACHE', $env:SCOOP_CACHE, 'Machine') 安裝 scoop scoop 就是這次重設環境的最重要工具，他的作用其實就跟老牌的 chocolatey 一樣，也跟 Mac 的 Homebrew 一樣。不過相對於 chocolatey，scoop 不需要 .NET Framework 4.x+ 就能執行，另外就是授權費用了， scoop 是 MIT 授權 ，是窮人的好朋友，不過也因為 bucket 是由社群提供，使用前翻閱 source code 還是比較好的，不要去選到一些私人的 bucket 你會比較有保障。官方的 bucket 可以到這邊，選擇有 official bucket 標籤的來源。 ...

前言 本文原作者 Mark Seemann, 10-tips-for-better-pull-requests, 15 January 2015, 譯者 Benjamin Rice (HENG CHIA, FAN) 1. 保持 PR 輕量 一個夠小、專注一件事情上的 Pull Request (以下用 PR 稱呼)對於 PR 的接受度會有很好的幫助。 當我收到 PR 通知的第一件事就是去看這個 PR 的大小。嚴格的審核一個 PR 是很花時間的，在過往的經驗裡審核 PR 花費的時間會依據大小呈指數成長而且裡面的關係基本上會很複雜。 若是在一個開源專案(Open Source project) 中收到 PR，我會意識到提交者很可能在他的空閒時間內投入了大量的工作，所以我也會投入一定的時間去審這個 PR ，即使我認為這個 PR 的 sizs 太大，尤其是當這個 PR 看起來像是首次貢獻者送出的。不過，若 PR 很大的話依舊需要排出時間來審，我無法用片段的時間來審一大段程式碼。 但若是在一個職場環境下收到 PR（例. PR 發起人是一個受薪的程式人員），我通常會因為 size 的關係將 PR reject。 至於 PR 要怎樣才夠小呢？顯然這個問題跟 PR 要處理的需求有關，不過一個 PR 少於一打的檔案還不錯。 譯者個人想法： 還滿認同這邊的論點，首先一個 PR 若東西太多會需要花費更多的時間去看，再來通常 PR 若是包了太多東西，若不是原需求太過複雜就是裡面偷渡太多跟需求無直接相關的內容。不過這件事情通常跟如何拆解一個需求有很高的相關性。而需求的拆分能力牽扯的範圍除了需求的理解、解決方案的選擇、既有框架的限制以及專案的上線時程與範圍等等，實在有點廣泛就不再這邊細聊了。不過這邊也是有一些例外的情境，像是專案使用的語言升級產生的異動(e.g. python2 upgrade to python3)，或是有些靜態檔案從專案移除搬去其他地方，諸如這種情況都會產生很多檔案的異動，我覺得反而這些放在一起比較好管理。 ...

Cutom Prompt Message 這邊說的 Prompt Message 是指什麼? 其實就在說當你打開指令模式時 (e.g. cmd, powershell, bash, etc…) 在你輸入指令的那前面一段顯示，通常預設會顯示當前的路徑，但你應該看過不少人把這段文字換成很多酷炫的樣式，通常你會在 Linux 使用者的電腦中看到這樣客製化的命令視窗，這篇文章就是要紀錄 Windows 的環境下如何作到客製話的命令視窗。這邊會以 PowerShell 為主要紀錄環境 CMD 也可以作到一樣的效果，只是我目前的工作環境皆已換成 PowerShell 來操作。 PowerShell Profile 基本上 PowerShell 也會有所謂的 profile 檔案，這個檔案相信對 Linux 的使用者肯定不陌生，而這個 profile 也是會分系統讀取，以及個別使用者的 profile ，當然位置會放在不同的地方，而且依據 PowerShell 版本的不同放置位置也會不同，而這篇主要是把這種客製化設定放在使用者層級。 PowerShell 5.x 的 profile 位置：about_Profiles PowerShell 7.x 的 profile 位置：about_Profiles Prompt function 不管是 5.x 或是 7.x 的版本，在 prompt 的異動上其實都一樣，差別就只有 profile 檔案位置的不同，所以以下就統一舉例說明。 ps. 但是要注意 5.x 跟 7.x 有些語法是有差異的，不能直接把兩者的 code 直接複製貼上 想要更改輸出訊息就直接重新定義 function prompt 就好，這個方法名稱不能換，因為系統預設就是會呼叫這個函式來組成輸出的樣式，但是因為沒有被保護所以可以讓我們直接複寫它。 ...

前言 ASP.NET core 的名字還沒記熟它又要改版本名了，不過對未來的發展這或許是好事吧。依據 roadmap 所示未來的版本名稱就會比較清楚一點。而在 .net 發長趨於穩定時開發應用時讓你又愛又恨的文件撰寫，你還在獨立寫一份嗎？程式碼跟文件之間的更新成本就不能在壓低一點嗎？若你還沒聽過 NSwag 的話這是一個你值得做的嘗試，另外不可或缺的就是 log 系統，你還在用 NLog 或是內建的日誌 lib 嗎？不體驗一下 Serilog 就太可惜了，尤其是目前應用多數跑在 container 裡，在系統 micro-service 化的現代裡，將 log 寫在本機裡在 container 數量漸多後管理上是有點麻煩，而 serilog 的外掛可以幫你把 log 直接送去指定的地方。 內文 本文將會基於 Asp.NET Core 3.1 版本來開發，雖然 .NET 5 已經推出但是它並非 LTS 版本所以並非首選。 本文的 source code 在 這裡 第一個步驟就是把必要的 Packages 裝一裝 1 dotnet add .\AspNetCoreSerilog\AspNetCoreSerilog.csproj package Serilog.AspNetCore 在 appsetting.json 直接將原本的 Logging 區塊取代為以下設定 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 { "Serilog": { "Using": [ "Serilog.Sinks.Console" ], "MinimumLevel": "Information", "WriteTo": [ { "Name": "Console", "Args": { "theme": "Serilog.Sinks.SystemConsole.Themes.AnsiConsoleTheme::Code, Serilog.Sinks.Console", "outputTemplate": "[{Timestamp:HH:mm:ss} {Level:u3}] {Message:lj} <s:{SourceContext}>{NewLine}{Exception}" } } ], "Enrich": [ "FromLogContext", "WithMachineName", "WithThreadId" ], "Properties": { "Application": "AspNetCoreSerilog" } } } 而在 Program.cs 也就是入口程式那邊補上以下程式 ...

前言 No-SQL 在目前的系統設計上面已經逐漸佔有舉足輕重的地位，當中有人使用老牌的 memcache 當然也有人選擇目前比較流行的 Redis，而這一篇就是要來記錄一下如何在 Windows 環境上安裝 Redis 並運行在 Docker 之中。 Why Run In Docker 在 Redis 官網中你是找不到有任何一個連結是 Windows 的安裝檔。沒錯！Redis 官方並不支援這樣裝，不過你可以在 Github 中找到微軟針對此提供的一個安裝方式，可以看到他其實也是從 Redis 官方的 repo fork 一份出來，版本可以從這邊選擇，但是可以看到從 2016 年後就已經沒有新的版本了，目前上面最新的載點是 3.2.1 這個版本，但是官方最新的穩定版本已經來到 6.0.8！官方載點清單可以在這邊找到，也因為 Windows 的版本是 2016 年 6 月推出的，已經是個過老的版本，於情於理都不再適合繼續用它來開發。不過官方對於 Windows 的支援度根本是零，難道 Windows 就是命賤嗎？ 不！其實只要你的 Windows 可以安裝 Docker (container 記得要選 Linux 的不要用 Windows 自己的 Container)那你就還是可以開心的使用 Redis，而且靈活性更大。 Redis with Docker 要在 Windows 下讓 Redis run 在 Docker 裡除了需要先安裝好 Docker 之外，就是要把 image 從 DockerHub 下載下來。這邊提供的下載選項滿多的，這篇就指明 5.0 版本號，因為 AWS ElastiCache 目前提供最新的版本就是 5.0，當然若是自建 Redis cluster 的話就可以直上最新版 image 來試試。 ...

前言 POSTMAN 通常是目前在做 API 層級的測試時的首選，不過通常 API 的測試不會只有 End-to-End 的測試就結束了，有些較完整的還會包含負載測試(Load Test)，不過若只有用 POSTMAN 就想要完成 Load test 那就辛苦了。 POSTMAN Test Script 這邊我們就使用 POSTMAN 自帶的 Collection (Postman Echo) 來做實驗，這邊簡單起見就只抓一個 Get method 來做。匯出的檔案大概會長以下這樣: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 { "info": { "_postman_id": "{_postman_id}", "name": "{your_collection_name}", "schema": "https://schema.getpostman.com/json/collection/v2.1.0/collection.json" }, "item": [ { "name": "{your_request_name}", "event": [ { "listen": "test", "script": { "id": "e6b1db6b-fac1-4f5c-820e-d0a6806b1a1e", "exec": [ "tests[\"Body contains headers\"] = responseBody.has(\"headers\");", "tests[\"Body contains args\"] = responseBody.has(\"args\");", "tests[\"Body contains url\"] = responseBody.has(\"url\");", "", "var responseJSON;", "", "try { responseJSON = JSON.parse(responseBody); }", "catch (e) { }", "", "", "tests[\"Args key contains argument passed as url parameter\"] = 'test' in responseJSON.args" ], "type": "text/javascript" } } ], "request": { "method": "GET", "header": [], "url": { "raw": "https://postman-echo.com/get?test=123", "protocol": "https", "host": [ "postman-echo", "com" ], "path": [ "get" ], "query": [ { "key": "test", "value": "123" } ] }, "description": "The HTTP `GET` request method is meant to retrieve data from a server. The data\nis identified by a unique URI (Uniform Resource Identifier). \n\nA `GET` request can pass parameters to the server using \"Query String \nParameters\". For example, in the following request,\n\n> http://example.com/hi/there?hand=wave\n\nThe parameter \"hand\" has the value \"wave\".\n\nThis endpoint echoes the HTTP headers, request parameters and the complete\nURI requested." }, "response": [] } ], "protocolProfileBehavior": {} } 這個方式的缺點就是 Postman 匯出的最小單位是 Collection ，所以很可能實際運用時你會需要把本機測試用的 Collection 與壓力測試用的分成兩個 Collection。 ...