两点:这真的是一个测试,你需要找到一种方法来减少运行所需的时间。
关于测试结构,您的第二个测试不是真正的独立测试。这取决于已经运行的第一个测试。这两个应该写成一个单一的测试。在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
)对您而言效果不佳,则可以编写自己的轮询。