跳到主要內容

Cucmber 環境設定 on Mac

因為最近開始開發iOS
但對於測試一直沒有很棒的解法
因此團隊成員發了狠，去徹底研究一個測試框架cucumber跟appium
這裏簡單記錄一下怎麼安裝與設定

主要是參考成員的blogger的設定，再用自己的理解記錄在自己的blogger這邊


  1. 首先要安裝 xcode，目的是為了 iOS 模擬器
  2. 第二步驟要安裝主角 cucumber 
    • terminal 中指令 sudo gem install cucumber
  3. 第三步驟是安裝Appium library
  4. 第四步驟安裝RubyMine IDE，目的是為了讀取 feature 檔案並可以透過 IDE 自動產生step 的語法
  5. 安裝 pry 套件，這個套件是為了debug用的，特別是他的killer feature "binding.pry"
    • terminal 中指令 sudo gem install pry 即可安裝
  6. 安裝 homebrew，這個是個套件管理工具提供
    • Homebrew 互補了macOS，可以使用 gem 安裝 ruby 套件，而利用brew來安裝依存軟體
    • 安裝方法 terminal 中打指令 /usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"
  7. 安裝 carthage，這個套件是類似於 CocoaPods 的功能，也是 iOS 套件管理用
    • terminal 中打指令 brew install carthage
到這已就完成了環境預備安裝
接下來就是打開appium server
然後在已經寫好 feature 的測試範例專案位置
透過 terminal 執行 cucumber 就可以跑測試

-------------------------------------------------------
reference:
https://dinoray123.blogspot.tw/2017/12/cucumber-mac.html
http://blog.xdite.net/posts/2012/08/13/pry-the-new-debugger
如何使用Carthage管理iOS依赖库

留言

張貼留言

這個網誌中的熱門文章

[學習iOS之路] Lifecycle 比較

在開發Android很多年之後終於開始學習寫iOS了 契機就是工作需要，果然工作需求就是推開最大靜摩擦力的原動力啊！ 在這邊寫下學習Swift的一些筆記，希望在自己忘記或是需要給別人教學的時候可以起到一點點作用。 因為對Android比較熟悉，所以透過比較來熟悉iOS架構 首先是iOS與android的比較 可以參考這張圖 Android vs iOS lifecycle 與這張 iOS 詳細state 流程 Android lifecycle OnCreate -> OnStart -> OnResume ->(running) -> OnPause -> OnStop -> OnDestroy                        ^                  ^                                  |               |                         |                  |-------------------v               |                         |-----<-----   OnRestart   ------<---------v iOS lifecycle LoadView -> ViewDidLoad -> ViewWillAppear -> ViewDidAppear -> (running) -> ViewWillDisappear -> ViewDidDisappear -> ViewWillUnload -> ViewDidUnload -> dealloc 於ViewDidDisappear之後view就看不見了，如果view要再次被看到且view還存在 那就會是ViewWillAppear，否則就是LoadView從頭開始 下一篇是語言的比較 Java vs Swift
張貼留言
閱讀完整內容

Docker vs VM 的學習

工作上用到 Docker 也一段時間了，剛接觸到 Docker 時常常會聽到別人這樣解釋，" Docker 的 Container 技術，類似於 VM 。差別是 Container 比較小，沒有包含 OS，而 VM 會包含 OS"。 這段話我覺得不算是全錯，所以我一開始也是這樣去解釋給別人聽，直到我聽到我同事在面試求職者時問了這句話，"如果 Container 比較快，比較輕量，優點這麼多，為什麼 VM 沒有被淘汰?" 我才忽然意識到，我並沒有真正瞭解這兩種技術的差別。 事實上，這件事情要從解決問題的角度上出發去理解。任何技術的產生應該都是為了解決某些痛點，從這點來思考的話網路上就有很多文章可以查到了，我把我查到的最清楚的文章連結放下本文最下方，有興趣的可以去看看。 VM 是為了解決硬體的資源共享的問題所產生出來的技術，而這個需求仍然存在，並不會因為有了 Docker 的 Container 技術就取代了。這個可以回答為什麼 VM 沒有被淘汰。因為要解決的問題不一樣，事實上很多 Container 還是跑在 VM 裏頭，可謂是相輔相成。 那 Docker 是為了解決什麼問題才發明的呢? 我的消化與理解是 "解決建置環境的複雜度" 而發明的，每個 Dockerfile 會指定使用的映象檔(image)，然後寫下需要安裝的 Tool 指令。按照這個 Dockerfile 上面列下的指令去安裝與建置，就可以重現執行這個 APP Runtime 所需要的環境。這解決了以前工程師常說的那句話 "在我的電腦上跑得好好的，為什麼在正式環境就行不通" 的問題。   參考連結
張貼留言
閱讀完整內容

C# CSRF attribute 的錯誤追蹤與處理

最近開發網站碰到一個問題，有時候可以登入成功，有時候不行。但明明帳密都是 Google 記憶的，不可能打錯帳號密碼。後來猜想到是 CSRF 認證的問題，由於網站是透過 k8s 建立的，且 replicas: 2。很大可能性是因為拿 token 是跟 A Pod 拿，但登入是跟 B pod 登入，造成 token 無法驗證成功。 想證明這個問題，我們必須去紀錄 Log，由於我們是透過 C# 的 ValidateAntiForgeryToken Attribute 實作 CSRF 的防禦，因此一開始想法是寫一個 ExceptionFilter 去攔截例外。但發現無法攔截 CSRF 的問題。後來找了一段時間發現，CSRF 並不是丟出例外，而是結果回覆 HttpStatusCode 400。查到可實作 IAlwaysRunResultFilter 攔截結果，並判斷是否是 IAntiforgeryValidationFailedResult 的一種。 程式碼如下:  public void OnResultExecuting(ResultExecutingContext context) { if (context.Result is IAntiforgeryValidationFailedResult result) { // Log here } } 但是這樣還不夠。還必須要強制關閉客戶端錯誤的轉換才行，這樣才可以精準的把結果視為 IAntiforgeryValidationFailedResult 至於怎麼關閉則是在註冊 MVC 服務的時候設定 Config SuppressMapClientErrors = true 即可。      services.AddMvc().ConfigureApiBehaviorOptions(options => { options.SuppressMapClientErrors = true; }); 詳細可以參考 MSDN
張貼留言
閱讀完整內容