ramaze testing for all 200 OK

日前聽到一個 controller testing 的說法，想想好像滿有道理的。
就是其實也不用寫很細，每一個 URI 都 GET 得一個 200 OK 就好。

這不用花多少功夫，但至少不小心改壞什麼，馬上就會知道，
也不用自己再一個個去看，也不需要用 watir 之類的東西...
詳細且完整的測試，非常耗費時間和功夫，對於經常需要修改，
變動規格的 controller 而言，做完整測試只是在浪費時間而已。

曾經寫過一些，結果發現一天規格變動一次，testing 重寫，
真的是會搞到翻桌。不過如果只是確保能回傳 200 OK,
那倒不是什麼問題，因為這牽涉到流程，比較不會修改，
更何況其實所有的 URI 應該是有辦法自動抓出，不用自己列。

當然，form 之類的 POST request 可能沒辦法測，
但現在所要的，本來就是最簡單，最省力的測試。

0% => 5% 其實也是很大的進步...

ramaze 在這點倒是還真簡單，我才看了幾分鐘而已 @@
拿他 prototype 裡面的 spec/main.rb 去改的。
這邊是在說，取出所有有 template 的 action,
藉此除去 POST action. POST action 絕對不會有 view, 是吧？

def gat uri
  get("/festival-of-light#{uri}")
end

def test uri, data
  gat(uri).status.should == 200
  last_response['Content-Type'].should == 'text/html'
  last_response.should =~ data
end

def yellow s
  "\033[1;33m#{s}\033[0m"
end

MainController.update_template_mappings # prepare
MainController.update_method_arities.keys.select{ |name|
  MainController.find_view(name, 'html')
}.each{ |action|
  should sprintf(yellow('%-8s '), action) do
    test("/#{action}", /<title>光祭 2009 | 城市之光‧從角落亮起來<\/title>/)
  end
}

而經過這次的一些 ramaze 實驗，我發現確實重點都在 innate,
ramaze 快要可以說只是一個 simple wrapper, for helper,
trait 之類的輔助用具。因此寫簡單的程式，其實用 innate 應該也行。

不過這不是重點。重點是 innate/ramaze 的模組化真的做得很好。
在 rails, 其實程式怎麼跑，你很難有什麼概念，除非你願意走入
rails source code 的 labyrinth 裡面。對不起，我放棄了 @@
曾經打算這樣過，但裡面太可怕了。

merb 其實是 better rails, 原則上他跟 rails 很接近。
rails 3 我暫時假設成 better merb, 至於 better 到哪，
等他正式推出時再看看。

然而 ramaze 在 每 一 個 地 方 都很清楚。
我覺得 Michael (manveru) 在這篇說得相當好：
Re: Is Ramaze secure enough to use for an ecommerce app?
如果你能掌控所有的東西，你就會很清楚你的東西是不是安全的。
當然這也是程度問題，我們不可能從 build a OS 開始，
有些東西是需要信任的。在這裡比方說，就是 rack.
rack 單純，簡單，容易證明他是正確且安全的。

rails 複雜，龐大，難以證明，只能期待有人會幫你把關好。
我想 drupal 應該也會面臨這樣的問題。一旦被發現漏洞，
全世界有多少網站受到影響，需要修復？而 drupal 是龐大
複雜的，會有各種問題一點都不奇怪。但 rack 太過於單純，
基本上一段時間沒被發現什麼問題的話，他幾乎就可以說是沒問題的。

我想 innate/ramaze 大概就是類似的概念，但他比 rack 大，
遠比 rails 小，好像跟 sinatra 差不多？

如果要一對一比較 ramaze 與 rails, 那很明顯的是，
rails 裡的一堆功能，ramaze 「全部」都沒有。
rake log:clear? 預設連 log 都沒咧。
ORM integrate? 當然沒有，什麼都沒有 XD
no config/database.yml, no config/blah

rails 的 database.yml 是怎麼讀取的？
他是怎麼連資料庫的？我一點都不知道，也沒興趣知道...
只知道連不上的話，還會卡死整個 passenger.

ramaze 怎麼做？自己寫自己的 config, 自己 setup.
我知道一定很多人只會用 rails, 他不知道 config 怎麼來的，
也不知道 database 怎麼連的。他只知道：

「我設好 config, 其他都會神奇地解決掉」

對於架網站而言，我覺得這樣的心態是沒問題的。
對於開發網站而言，我覺得這樣的心態沒辦法開發出什麼東西。
隨便換個什麼東西，立刻就死在那.....
ptt Ruby 板看到一堆類似的問題，實在很想叫他們重新念書。
還是乖乖學會 +- 再來玩 */ 吧... 這跟建構式數學無關 XD

所以在 ramaze 裡，我很清楚 ramaze 怎麼讀入記憶體，
程式從哪裡開始，（拜託不要把 main 藏起來！這是我覺得
Qt 很棒的一點，你還是可以用 main, 而不是神奇 macro）
controller 何時讀入，model 何時讀入，整個程式流程是什麼？

因此可以有一個很簡單的 ruby script 跑起整個程式，
也可以透過 rackup/unicorn 跑 config.ru,
甚至連 controller 本身，也是 rack middleware!

Node#resolve 做 routing, 得到 Action,
Action 怎麼讀取 template, 最後畫出結果，
程式碼都沒幾行，非常直接且直覺。

我猜可能花不了幾天，可能就能把 innate/ramaze 架構讀完。

我覺得這才是良好的 ruby 程式，這才有 duck typing 的精神。
rails 你隨便換個東西就爛掉，看似模組化，其實是巧妙平衡。
不過或許這也是 trade off, 希望讓使用者啥腦都不用動，
底下就得做很多神奇的事情。就好像猜測人心一樣，不搞得很複雜，
真有可能猜到「每一個人」心裡在想什麼？ramaze 絕對做不到。

或許 rails 神奇迷人的地方在這。

但想走遠一點的話，我覺得還是需要試著往其他地方走。
一個真正的架構，很多時候是需要針對特殊情況去寫的。
我覺得 rails 實在比較適合小專案。如果說需要調教到能用，
需要走很長的路的話，何不一開始就自己開發？

rails routes 實在搞得非常恐怖，走火入魔了。
慚愧，卻曾經覺得很漂亮... 但其實一點都不實際。
這邊我正在改寫，成功改寫完的話，
搞不好可以整個搬到 ramaze 上。
因為我幾乎所有的程式都不是針對 rails 寫的。
（model 有 datamapper 的一份，同時開發的 lol）
再來大概就是 form helper 比較麻煩點，這邊也要全拆掉。

也許 c++ template 也是類似的狀況。

不過我想大概每個會著迷於技術的人，都曾經走過這一段吧（遠目）

總之 innate/ramaze 真的很不錯，應該早點試的。

==
噢對了，rails 的 console 是用 shell 呼叫 irb,
所以如果 irb 不在 PATH 的話，應該會死。
而且 irb 用的 ruby 和 script/console 的 ruby 還會不同。

而 ramaze 雖然沒去看，但應該是讀進記憶體吧？
就完全不會有這種麻煩的問題。library 就是要這樣用啊！
別把程式跟 shell 綁在一起... 移植性會變很差。

updated: 求證了，在這：

require "ramaze"
require "irb"
require "irb/completion"
Ramaze.options.started = true
require "start"
IRB.start
puts "Ramazement has ended, go in peace."

簡單易懂。