最近哥工作终于没这么忙了，整理下之前的一些问题。
原文：http://www.cnblogs.com/hyddd/p/4126979.html

Robotium 的左右为难 -- enterText

• 最近测试框架收到反馈，详查后发现了一个 Robotium 的问题，甚有趣，遂记录。

问题场景：

• Robotium.enterText 输入数据后，点击"发送"按钮，多数情况下失败，少数时候成功。

问题分析：

• 这个问题不需要深入的分析流程，直接看 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。

1. 为什么 Robotium 要这么做呢？

• 如果不这么做，editText.setText(msg) 也成功。但这和真实操作不一致，真实流程是：点击 editText，弹出键盘，输入文字，隐藏键盘。虽然这个流程短，但状态变化很大：
  • 焦点发生变化，这可能会影响后续的检查/业务流程（触发事件之类…）。
  • 弹出/隐藏键盘，这会触发 Android 从 Touch 模式变为键盘模式。另外弹出/隐藏键盘可能有监听事件，如不触发操作，监听事件不会执行。

2. 为什么要在 setText 之前 hideSoftKeyboard？

• 如果 performClick 和 hideSoftKeyboard 是上面的原因，那么 hideSoftKeyboard 在 setText 之前/后都没所谓了，因为他压根不影响输入。

3. 如果不执行 hideSoftKeyboard 会怎么样？

• 隐藏键盘的监听事件不执行。
• Android 将停留在键盘模式。
• 最重要的是：不藏起来，键盘一直占了半个屏啊，Robotium 要可视控件才能操作，弹出键盘可能会影响其他控件的操作。
  • 这么说，Robotium 在 enterText 的时候做 performClick 和 hideSoftKeyboard 是很合理的。

回到之前的问题，为什么它会导致 “信息发送失败” 呢？

• 因为这个产品设计是，藏起键盘时，bottom_bar 会回退到初始状态。如图：
  • 
• bottom_bar 初始状态时，是没有输入框和发送按钮的。先不管 edit 和 btn 有没被 GC，光控件不可视，click 操作就会失败。至于成功/失败随机，是因为 hideSoftKeyboard 事件响应和 click 速度参差造成的。
• 只能说这种应用场景下，Robotium 表示无能为力。

解决方案：

1. 对 Robotium 进行扩展，实施额外 enterText 接口，但这会对日后升级 Robotium 带来不便。
2. 修改案例避免问题。