關於 #教學 的內容

在上一個段落中，我們有提到需要限制 Let 的使用，然而當我們有比較複雜的測試前置條件時，就很難避免撰寫過於複雜的測試主題，此時就可以利用「前置處理」的機制來解決這個問題。

了解如何撰寫基本的測試後，我們需要學習如何組織一個測試。在進行單元測試的時候，我們不太可能單純針對一個方法測試，而是會針對整個物件進行驗證，因此需要區分不同情境、測試目標。

在我的經驗中，要將測試寫好並不是一件容易的事情。很多時候，我們會看到不少「測試」是難以閱讀的，這也讓我們很難了解到測試的意圖，因此我們要先針對「結構」進行一些討論。

幾乎所有的 Ruby 開發者都聽過 RSpec 然而 Rails 和 Ruby 都是使用名為 Minitest 的測試框架進行測試的，那麼 RSpec 做了什麼事情，讓更多開發者比起使用 Minitest 更喜歡使用 RSpec 呢？

撰寫測試的方式有很多種，如何為軟體加入測試也是一門深奧的學問。我個人是比較推薦使用 A-TDD（Acceptance Test Driven Development，驗收測試驅動開發）跟 TDD（Test Driven Development，測試驅動開發）兩種方式來進行開發。

測試幾乎是現代軟體開發的必備技能，然而我們對於測試的理解、撰寫、使用的熟練程度，會極大的影響我們的軟體是否穩定，也因此具備一個優質的測試技能對於軟體的品質與改善都會有非常大的影響。

當我們完成部署後是一個更大的任務開始，我們仍然還有許多的任務需要處理。舉例來說，我們還需要對網站加入各種類型的監控，並且持續的追蹤各項指標（Metrics）的變化，持續的改進。

Review Apps 是 GitLab 所提供的一個機制，可以用於針對某個 Merge Request（合併請求）來自動部署給用來進行 QA（Quality Assurance）驗證或者專案經理檢查功能的機制。因為我們已經可以進行自動化的部署，也因此可以用來產生 Review Apps 進行驗證。

Heroku 也有提供 Review Apps 的方案可以跟 GitHub 搭配，可以根據需求調整。

當我們從 Docker Compose 轉換到 Docker Swarm 之後，仍然還是面臨需要人工進行部署操作的狀況，因此我們還需要更近一步的利用 GitLab CI 來幫助我們解決部署的人工操作。

部署的環境已經準備好後，我們就可以來將之前所撰寫的 Docker Compose 設定檔轉換為 Docker Swarm 支援的格式，以及調整我們的架構來讓專案可以被部署到 Docker Swarm 上面。