2012-07-28 69 views
1

我使用Ruby on Rails開發了一個類似風險的遊戲,我必須開發一個程序來隨機地在角色之間調度區域並隨機地調度角色的單位到他們的領土。測試「複雜」操作:類似風險的棋盤遊戲部署

遊戲有5個字符的42個地區。 3個字符接收8個地區,2個字符接收9個地區。每個角色都有25個單位的池(27個用於9個地區的單元)在分配的區域內分配。每個領土最終必須至少有1個單位。

我的模特如下。如果需要,我可以改變它。

  • 用戶;
  • 遊戲;
  • 面積;
  • 角色,將用戶綁定到遊戲,持有剩餘單元進行部署;
  • 區域,將一個字符鏈接到一個區域,持有該區域的單元數量。

現在這裏是我的想法。

  • 我應該分開兩個操作(領土調度和單位調度),即使它性能較差;
  • 爲了更容易測試,輸出狀態應該與輸入相同:隨機部分應該來自外部。

你會爲這種情況寫什麼斷言? 我使用默認的Rails 3測試堆棧:Test :: Unit和Fixtures。

The code is available on GiitHub

謝謝!

+0

從未玩過風險,但我想知道初始隨機定位可以被編碼爲某種遞歸方法的程度。如果可以的話,測試會很容易:在設置最後位置前的步驟(N-1)時,定位方法的結果將屬於有限集合。你在這裏有一個規格。 – apneadiving 2012-07-28 09:50:28

回答

1

你需要看起來很簡單的斷言:

  • 本場比賽有42個地區

  • 爲5個字符。

  • 3個字符接收8個地區,2個字符接收9個地區。

  • 每個人物都有的25個單位

等等池...

我的模式有以下幾種。如果需要,我可以改變它。

  • 用戶;
  • 遊戲;
  • 面積;
  • 角色,將用戶綁定到遊戲,持有剩餘單元進行部署;
  • 區域,將一個字符鏈接到一個區域,持有該區域的單元數量。

現在這裏是我的想法。

  • 我應該分開兩個操作(領土調度和單位調度),即使它性能較差;
  • 爲了更容易測試,輸出狀態應該與輸入相同:隨機部分應該來自外部。

作爲一個方面說明,我想你已經在前期設計了比遠遠不夠多在這裏。 TDD應該讓你的代碼的設計出現和發展,所以儘管你一開始就可以堅持這些預先建立的規則,但是當你編寫測試的時候,你不應該害怕修改它們,甚至完全擦除它們。

測試驅動器實現的最佳方法是先進行第一個測試,然後再進行......然後逐步發現最佳設計似乎是什麼,而不是從一開始就嘗試構建完美模型。

-1

會不會有某種PlayerSelector有用?

也許方法Player selectPlayer()或播放器ID。 然後,你可以做某些CyclicSelector存根確定性選擇... 你選擇的第一個國家去玩家1,第二個玩家2,3,1,2,3等。