Your first question:
... all of the tutorials I see for Serverspec use should rather than expect. Is this because Serverspec hasn't been updated to use expectations?
No, it is mostly because the author of the Serverspec project has a preference for the "should" syntax, and that's why the Serverspec documentation continues to use it. He has explained here that:
I'm using should syntax instead of expect syntax because I think should syntax is more readable than expect syntax and I like it.
Using expect syntax is recommended way because adding should to every object causes failures when used with BasicObject-subclassed proxy objects.
But the one-liner syntax used with the examples in this page doesn't add should to any objects, so this syntax doesn't cause the above problems. That's why I'm using the one-liner should syntax.
Be aware that should and expect come from the rspec-expectations project, and the Serverspec author is correct "should" rather than "expect" is fine the way he is using it.
There is more info on the original motivation for the expect syntax from the Rspec author Myron Marston here.
Your second question:
... how would I write the test using expectations instead of should?
If you still want to use the expect syntax, just replace should everywhere with is_expected.to everywhere. This works fine:
describe file("/etc/passwd") do
it { is_expected.to be_file }
its(:content) { is_expected.to match /root/ }
end
You can also write it this way:
describe "passwd file" do
it "the passwd file should be a file" do
expect(file("/etc/passwd")).to be_file }
end
it "and it should contain root" do
expect(file("/etc/passwd").content).to match /root/
end
end
Or even:
describe file("/etc/passwd") do
it { expect(subject).to be_file }
it { expect(subject.content).to match /root/ }
end
See also: