經過昨天用 atm 與捷運門來解釋單元測試與整合測試後，不知道大家有沒有清楚。我早上起床聽著以前最愛的 Evanescence - Bring me to life 後，突然想到可以用樂團來解釋，所以今天就讓我們用樂團來理解所有測試類型是什麼概念。

Day1 時，我們淺談了測試的重要性；測試在工程師們的眼中是何等存在？浪費時間？但似乎又很重要？

在我們實際看到測試到底是什麼東西前，先讓大家了解測試的類型有哪些。

為什麼會想寫這個主題?

常常在IT邦裡挖到不少含金量高的乾貨，讓我在學習時學到了很多觀念；在IT邦挖礦的過程中，意外發現程式設計裡竟然還有專門用來測試工程師們所寫的code是否能正常運作的「測試框架」。這個測試框架當然也是由工程師寫出來的程式碼所組成，所以無論是專案或是測試都是由工程師code出來的。

所以意思是，專案歸專案，測試歸測試，兩個是分開來的，要麻就是寫專案，要麻就是兩者都寫。

前言

當我們在寫專案時，有很多的功能會寫在各自的 MVC 裡。

但當這項功能是 CRUD 以外的功能，我們究竟要把它寫在哪呢？

Service

通常這類功能，像是金流串接，需要將參數加密後發 request 到金流廠商，接著再接收金流廠商發過來的 request 並解碼，再回傳相關資料。

前言

上一篇，我們主要介紹了 GitHub，這篇我們就來講講跟他名字很像，但實質上完全不同的 Git 工具。

簡單來說，我們可以透過 Git 指令，讓檔案進行版控。

前言

GitHub 是業界中廣為人知的版本控制網站，它是使用 Rails 建構（一定要提一下ＸＤ）。

只要輕輕地使用 git 指令，便能將檔案推上網站，或是從網站上拉下來。

等等，一下 GitHub 一下 git，有什麼差嗎，為什麼會用兩個不同的詞？

就讓我們繼續看下去。

前言

在 Rail 的 MVC 架構中，M 是負責驗證與邏輯、以及轉譯向資料庫溝通的角色; C 是負責資料的搬運，搬往 M 或 V; V 則是負責畫面的呈現、及使用者與資料的互動，並將請求送往C，接著得到 C 送回來的資料。

那關於資料的傳輸，一定是要先有個表單，Rails 提供了三個方法，依照需求使用，不過用過之後，通常就會知道哪個最好用。

將 Rails 環境帶入 rake 裡，讓 rake 可以使用 Rails 的元素，像是 Model：

1
2
3
4
5
6
7

namespace :user do
  desc "建立使用者"
  task :init => :environment do # 讓 rake 可以引入所有 rails 的東西（ model, migration 等等）  
    User.create(email: Faker::Internet.email ,password: '123456')
    puts "user created"
  end
end

前言

在介紹什麼是樂觀鎖、什麼是悲觀鎖之前，我們先來了解一下，這兩個鎖是應用在什麼地方？

資料庫

資料庫是用來處理資料的讀取與寫入，而資料庫的交易行為 (transaction) 必須符合 ACID，其中的 I 為 Isolation，指的是資料庫在對同個資料同時進行多筆交易時，必須避免產生資料的不一致。

前言

在 Rails 裡常常可以看到 redirect_to 與 render，前者是用來轉址，後者則是用來渲染畫面，這樣聽起來，根本上的就差異很大了呀，為何還需要拿來比較？

沒錯，他們在根本上的差異是不同的，但如果我們將不同的方法使用在相同的畫面上，這其中的細節，就耐人尋味了。