2013-12-17 28 views
8

背景:我正在開發一個項目,該項目使用Celery來安排將在特定時間運行的任務。這些任務推動了最終狀態機的狀態。下面是一個例子:運行一個連接到Django測試數據庫的芹菜工作者

  • 將來的提醒計劃在2天內發送給用戶。
  • 當該計劃的任務運行,電子郵件發送,並且FSM前進到下一個狀態
  • 下一個狀態是安排在提醒在兩天
  • 當此任務運行時運行,它會發送另一封電子郵件,推進國家
  • 等...
我目前使用CELERY_ALWAYS_EAGER通過 this SO answer

使用該技術在測試中的問題的建議

,是個在任務代碼中,這意味着在一個單獨的線程中運行,它與調度它的那個運行在同一個線程中。這導致FSM狀態不能正確保存,並且使其難以測試。我一直無法確定究竟是什麼原因造成的,但它看起來像在保存到當前狀態的調用堆棧底部,但是當您返回調用堆棧時,以前的狀態正在保存。我可能會花更多的時間來確定代碼在運行時應該如何發生錯誤,但試圖讓代碼運行它應該如何並確保它正在做它應該做的事情似乎更符合邏輯。

問題:因此,我想知道是否有一種方法可以運行一個完整的芹菜設置,django可以在測試運行中使用。如果它可以自動運行,那將是理想的,但即使是一些人工干預也不如手動測試行爲。我在想,如果我在測試中設置一箇中斷,運行芹菜工作者連接到測試數據庫,繼續django測試,那麼可能會有些事情可能發生。有沒有人嘗試過這樣的事情?

+0

我猜這是一個替代方案,可以編寫一些不使用Django測試運行器的單元測試,因此使用主(開發)數據庫,進行數據的手動設置和拆卸。 – Andres

+0

是的,這可能是最簡單的方法。我這樣做是爲了在一個大的數據庫上運行測試,而這個測試不適用。 – joshua

+0

我不知道這是否是你的問題,但是我有一些關於Celery Tasks不通過Django中間件的事實的競爭條件,所以數據庫操作不是事務性的。 這可能是奇怪的數據庫行爲的原因 – geekazoid

回答

1

你所要做的不是單元測試,而是功能/集成測試。

我建議使用一些BDD框架(Behave,Lettuce),並從CI服務器(TravisCI或Jenkins)對外部服務器(例如臨時環境)運行BDD測試。

所以,這個過程可能是:

  1. 更改推到GitHub的
  2. GitHub上啓動建立CI服務器上
  3. CI服務器運行單元測試
  4. CI服務器部署到集成環境(或分期,如果您沒有集成)
  5. CI服務器針對新部署的代碼運行集成端到端測試
  6. 如果一切成功,這個版本將被提升爲「可以部署到產品」或類似的東西
相關問題