最近測試框架收到反饋,詳查後發現了一個Robotium的問題,甚有趣,遂記錄。框架
問題場景:ide
Robotium.enterText輸入數據後,點擊"發送"按鈕,多數狀況下失敗,少數時候成功。測試
問題分析:spa
這個問題不須要深刻的分析流程,直接看enterText源碼即可發現大概問題:設計
public void setEditText(final EditText editText, final String text) { if(editText != null){ final String previousText = editText.getText().toString(); inst.runOnMainSync(new Runnable() { public void run() { editText.setInputType(InputType.TYPE_NULL); // 設置input類型,不重要 editText.performClick(); dialogUtils.hideSoftKeyboard(editText, false, false); if(text.equals("")) editText.setText(text); else{ editText.setText(previousText + text); editText.setCursorVisible(false); // …爲何text.equals("")就不須要呢setCursorVisible(false)呢?這TM在玩我吧......算了這個也不重要... } } }); } }
重點是performClick和hideSoftKeyboard。code
1. 爲何Robotium要這麼作呢?orm
若是不這麼作,editText.setText(msg)也成功。但這和真實操做不一致,真實流程是:點擊editText,彈出鍵盤,輸入文字,隱藏鍵盤。雖然這個流程短,但狀態變化很大:blog
(1)焦點發生變化,這可能會影響後續的檢查/業務流程(觸發事件之類…)。接口
(2)彈出/隱藏鍵盤,這會觸發Android從Touch模式變爲鍵盤模式。另外彈出/隱藏鍵盤可能有監聽事件,如不觸發操做,監聽事件不會執行。事件
2. 爲何要在setText以前hideSoftKeyboard?
若是performClick和hideSoftKeyboard是上面的緣由,那麼hideSoftKeyboard在setText以前/後都沒所謂了,由於他壓根不影響輸入。
3. 若是不執行hideSoftKeyboard會怎麼樣?
(1)隱藏鍵盤的監聽事件不執行。
(2)Android將停留在鍵盤模式。
(3)最重要的是:不藏起來,鍵盤一直佔了半個屏啊,Robotium要可視控件才能操做,彈出鍵盤可能會影響其餘控件的操做。
這麼說,Robotium在enterText的時候作performClick和hideSoftKeyboard是很合理的。
回到以前的問題,爲何它會致使「信息發送失敗」呢?
由於:這個產品設計是,藏起鍵盤時,bottom_bar會回退到初始狀態。如圖:
bottom_bar初始狀態時,是沒有輸入框和發送按鈕的。先無論edit和btn有沒被GC,光控件不可視,click操做就會失敗。至於成功/失敗隨機,是由於hideSoftKeyboard事件響應和click速度參差形成的。
只能說這種應用場景下,Robotium表示無能爲力。
解決方案:
1. 對Robotium進行擴展,實施額外enterText接口,但這會對往後升級Robotium帶來不便。
2. 修改案例避免問題。