Conversation
1. When seed is not sent 2. With response status in cli being 0 even when failures appeared
Add seed paramter to turbo tests
4042794 to
152e694
Compare
|
I did it separately from #33 but maybe I shouldn't . Example 1it "one" do
record = build :record
expect { record.save }.to eq(true)
end
it "two" do
record = build :record, id: 1
expect { record.save }.to eq(true)
endIn this simple example, order "two, one" will succeed but "one, two" will fail. Example 2A more real world (I had that exact problem on some old spec last month) example is setting thread variables and forgetting to unset them later. # file1.rb
let(:client) { create :client }
...
it "saves currrent_user_id in execution_context_store" do
expect { complex_class.new(user: client).call }.to change(Thread.current[:execution_context_store]).from(nil).to({client: client})
end
# file2.rb
after do
Thread.current[:execution_context_store] = {}
end
describe ".store" do
before do
Thread.current[:execution_context_store] = { some: "value" }
end
it "returns value stored in current thread 'execution_context_store'" do
expect(described_class.store).to eq(some: "value")
end
endIf file1.rb will be on same thread will be before file2.rb and won't be cleared with "after" we will have an error. Why would it be beneficial?Printing failing group, prints tests that were in that group. If we combine it with seed option, we can do Let's assume we have an example 2 # file3.rb
after do
Thread.current[:execution_context_store] = {}
end
...Let's assume turbo_tests seed 4321 -n 2 will return order: Thread1: "file1.rb, file2.rb", Thread2: "file3.rb, file4.rb" |
Why this option is useful?
If you stumble across random failures you can debug it easier.