-
Notifications
You must be signed in to change notification settings - Fork 27
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add option to print failing group #34
base: master
Are you sure you want to change the base?
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
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks, @mRudzki 👍
Why the regular failure RSpec output is not enough?
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)
end In 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
end If 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.