P12 發現動作組合後的陷阱

在很多時候，只看單一動作的實現步驟時感覺不到任何異常而認為合理，但不知為什麼只要把幾個動作組合為功能實作後，就會發生意想不到的問題。整合測試與使用者測試除了要確認完成功能所需的動作是否依序執行之外，同時也要找出動作組合後才看得到的潛在問題。

UI是最容易產生陷阱的地方。例如focus的改變可以即時呼叫requestFocus()，但是在呼叫在內部會以另一個Thread來進行動作，這就會產生時間差的問題；有時誤以為呼叫後會立即生效，就接著在後面寫上預期focus已經移動的程式，問題有時就這麼出現。另一個可能是有兩個動作都有對不同UI元件requestFocus()的動作，這在各自檢視動作時並無不妥，可是兩個動作在同一個流程內一起經過時，就會發現focus有時會落在另一個UI元件上。

在流程內應該只執行一次的動作（像requestFocus()）被呼叫過兩次就有可能產生問題，從流程上來看應該是經過所有動作的同時判斷該不該作那個動作。因此含有那個動作的方法可能會增加“要不要執行那個動作”的參數，或者是把那個動作另外拉出成另一個方法在流程裡自行呼叫，一切端看怎麼做最合邏輯。

在這個階段還有可能作方法的重構，是一定要具備的心理準備，如果動作不能迅速而安全地搬移或拆解，就會在此時付出嚴重的side effect代價。

註：有時在組合動作裡難以決定要怎麼做，那時會在被重覆使用的地方加上synchronized以保證一次只有一個thread進入。即使做兩次是浪費資源，但是至少每一次的結果都是正確的。