---
title: "優雅的 RSpec 測試 - 前言"
date: 2023-01-06T00:00:00+08:00
publishDate: 2023-01-06T00:00:00Z
lastmod: 2023-09-03T14:30:07+08:00
tags: ["RSpec","教學","測試"]
series: "elegant-rspec"
toc: true
permalink: "https://blog.aotoki.me/posts/2023/01/06/elegant-rspec-preface/"
language: "zh-tw"
---


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

<!--more-->

## 測試的目的{#the-objective-of-test}

在現實世界中，機械也有可能發生一些不可預測的問題。更何況是由人類來撰寫程式，當我們將規格轉換為可以運作的軟體時，就有可能出先一些跟預期不同的情況，在這種時候我們就會需要測試來進行驗證每一次的修改沒有破壞原有的行為。

這是一種確保品質的手段，因此我們會有各式各樣的測試去針對我們所製作的軟體（或者產品）來進行進行品質上的檢查，這些手段就包含了人工進行的 QA Testing（Quality Assurance，品質保證測試）以及可以自動進行的 E2E Testing（End to End，端對端測試）測試和 Unit Test（單元測試）等等不同層級的測試。

## 自動化測試{#automatic-test}

對工程師來說，最常接觸到的就是自動化測試這類需要撰寫「程式」去處理的部分。既然被稱為「自動化」測試，就表示這些測試必須要能夠自動執行，也因此這樣的測試必然可以大量、重複的被執行，也因此會是整個軟體測試的主要部分。

如果我們想要提高軟體交付的頻率，就表示需要對每一次的調整、修改都具備一定水準的信心，要達到這樣的條件，在每一次的修改、合併中加入自動化測試，就能夠一定程度的保證這些變動不會破壞原有的功能，至少在有測試的範圍內運作起來都是相同的。

這也是現代軟體開發中實現「持續整合（Continuous Integration）」的重要條件之一，即使我們可以持續的合併原始碼，卻無法保證合併後的原始碼可以正常運作，那麼只會造成更多的問題。有了自動化測試，我們就能夠減少這樣的問題發生。

## 如何驗證測試{#how-to-verify-test}

另一方面，我們應該要如何驗證測試是正確的呢？實際上我們實際上實作的程式也反應了測試的正確性，假設我們的測試是正確的，那們我們實作的程式也就能夠正確的運行。

因為我們在測試中撰寫的是「規格」的資訊，也就是說當我們遺失了所有的產品原始碼，只要測試還繼續存在，我們即使使用了完全不同的實作，也能夠重現出相同的系統和功能。這也構成了我們得以隨時對產品進行重構的前提，只要重新實現的功能符合我們對功能的「規格定義」那麼即使原始碼完全不同也不會破壞我們的系統。

## 理解就不難{#not-hard-if-understand}

在我過去的經驗中，一直覺得撰寫測試是很難進行跟撰寫的工作。也因此，大多數時候我們會下意識的「逃避」或者「偷懶」去撰寫測試，然而當我們熟悉測試框架、測試的目的，會逐漸發現撰寫測試是一件舒適且愉快的事情。

從這幾年上來的課程、書籍之中所彙整的經驗，如果我們所開發的軟體只有「功能」本身，實際上是不完整的，還需要加上測試互相驗證，才得以成為一個足以長期維護、改善的軟體。同時，在學習撰寫測試的過程中也能夠逐漸的學習將程式碼優雅的撰寫與設計。

---

如果想在第一時間收到更新，歡迎[訂閱弦而時習之](https://mailchi.mp/aotoki/graceful-rspec)在這系列文章更新時收到通知，如果有希望了解的知識，可以利用[優雅的 RSpec 測試回饋表單](https://us4.list-manage.com/survey?u=dd3d68032c0510041f1302539&id=5ddf86cae1&attribution=false)告訴我。