兩點:這真的是一個測試,你需要找到一種方法來減少運行所需的時間。
關於測試結構,您的第二個測試不是真正的獨立測試。這取決於已經運行的第一個測試。這兩個應該寫成一個單一的測試。在RSpec中,煙霧測試最好寫成feature specs(不是因爲水豚一體化,而是因爲feature
和scenario
語法在概念上對於驗收測試是正確的)。在單一場景中有一組以上的期望是合適的。所以,作爲一個第一次通過,我會這樣寫:
feature "Smoke tests" do
context "Logged in" do
scenario "User starts a long-running process" do
# Do whatever starts the process
# Expect the initial (immediate) results of the process
sleep 20 * 60
# Expect the asynchronous results of the process
end
end
end
關於測試運行時,這將是可怕的得你每次運行一個20分鐘的單次測試煙霧測試版本的軟件。 任何你可以做的事情,以減少20分鐘將是一個巨大的好處,貴公司。我不知道爲什麼它需要20分鐘來測試你在測試的過程中,但這裏有三個方面的考慮:
如果居然有20分鐘的工作(計算)做的,給煙測試更少的工作。例如,如果完成該過程的時間取決於輸入數據的大小,則爲其提供一組要處理的最小數據。
如果這20分鐘的一部分只是一個任意延遲,請爲特權用戶提供一種方法來控制延遲並在您的煙霧測試中使用該機制將延遲設置爲儘可能小的值,同時仍然存在作爲煙霧測試有效。將該機制添加到生產代碼中(而不是像存根那樣做一些特定的測試),以便煙霧測試仍在測試生產代碼。
如果這20分鐘的一部分只是等待足夠長的時間以確保該過程已完成,則通過輪詢將其最小化。 uzzer提出的rspec-wait gem就是這種策略的一個很好的例子。如果rspec-wait的等待算法(它只是檢查每個wait_delay
,直到它達到wait_timeout
)對您而言效果不佳,則可以編寫自己的輪詢。