徵 Ruby on Rails Developer 同事
Junior 0-2 年經驗左右都可，薪水依照能力談，基本薪資範圍如 Yourator 上的資訊
⚠️注意
- 完全沒寫過 Ruby / Rails 的不要來投，因為最低要求是至少要懂 Rails 基本的 CRUD 實作
👇 基本要求
- 能夠以 Rails way 實作基礎的 CRUD 功能
- 了解 Database relation one-to-one / one-to-many / many-to-many 如何設計
- 對 SQL / NoSQL 有基礎認識及使用場景
- 對單元測試有稍微認識（你可以不會寫，但要知道這個可以做什麼）
🥺 加分項
- 做過全棧營的 Rails 百寶箱並且有 Repo
- 做過 Rails 12 in 12 並且有 Repo
- 做過 Rspec 101 並且有 Repo
- 做過 Rails 101 並且有 Repo
- 寫過部落格
如果你想知道面試會被問什麼
- 請看 https://blog.niclin.tw/2020/01/07/interview-tips/
想知道關於公司氛圍或其他
- 直播存檔 https://www.youtube.com/watch?v=N0nD-ipOR70
- 去年尾牙 https://www.youtube.com/watch?v=iwUwSz5R3cg
投遞方式
直接 Yourator 投遞就好
https://www.yourator.co/companies/BitoEX/jobs/18900
單元測試 範圍 在 Re: [請益] 如何實現單元測試多於整合測試？ - 看板Soft_Job 的美食出口停車場
先確認一下，不知道你們是不是用一些潮潮 der 框架，
然後那框架的官方文件給的範例是看起來簡潔漂亮清楚的一兩行 code，
(例如 service 裡一個查詢 > return 結果)
然後你們把範例 copy 過來改，直接往裡面塞邏輯？
如果是這樣，可能需要先做的是把 CRUD 分割出去，
把所有 "用某些參數組一些查詢取得查詢結果" 這樣的東西包出去變成方法呼叫。
這樣做之後，應該就能很容易的 mock 掉 CRUD 的部份
然後我覺得更好的情況會是把商業邏輯也包出去，
這樣就可以從 service 層再切出更核心更通用的 core 部份，
core 的部份不依賴於任何框架或外部環境，
只包含 "接收資料處理邏輯回傳資料"
這樣做之後，應該就能很單純的直接給資料測 core 的部份，無需任何 mock
(或者說 mock 就是 testing data 本身)
然後哪一種測試要多是依你們的需要而定，
通常整合測試可以 "花較少的時間力氣測較大的範圍"，
如果需要的是做上 production 之前的防護網會比較適合
單元測試足夠則可以 "較明確的指出目前有問題與確定正常的部份"
如果需要的是遇到問題時能快速的排查與修復就多加一些
※ 引述《a804372004 (忽冷忽熱摸不著)》之銘言：
: 將單元測試實作於專案時，發現絕大部分API都是針對資料庫做CRUD，這部分程式透過in
: memory 寫了整合測試，越寫越覺得不對勁，心想單元測試數量不是應該要最多？ 網路文
: 章、影片或實體書籍大多也在探討如何寫單元測試，整合測試資源相對少，在想是不是我
: 哪裡做錯了，懇請各位大神指教。
--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 36.226.175.248 (臺灣)
※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1668932484.A.DB0.html
那的確是，假如都是單純的 API 讀資料庫回傳結果這類操作，
基本上也沒什麼東西能拿去做單元測試
單元測試我覺得有幾類比較需要 :
1. 底層核心，偏 utils 的，例如 距離計算，日期的格式化或 parse 等
它們可能被廣泛的用在許多地方，比較不能出錯
2. 本身內部邏輯複雜的，例如依多項參數計算費用或生成合約
它們如果出錯 debug 難度會較高，
有單元測試可協助快速縮小可能出問題的範圍
3. 被用在很多步驟的一組流程中的，例如要打多個 API 的一組流程，
如共享交通的借還車，這類型的當有問題但整合測試測不出來時
(例如打 API 的順序不對，整合測試也沒測該順序的 case)
若有單元測試則可快速確認是不是底層實作的問題，
如果確認不是就能很快的調整排查的方向
不那麼直接
有 "好的邊界與流程" 會好測試，而 OO 是實現的手法之一，
不過不是唯一的方式，也不保證使用 OO 必然能實現 "好的邊界與流程"
※ 編輯: lovdkkkk (111.241.166.152 臺灣), 12/01/2022 12:21:42
... <看更多>