I disagree with the explicit input and output making it any easier to read. Yeah, you don't have to go looking at another file, but you still end up splitting your text window so you can make sure the explicit declarations of what's on the cookbook server matches the explicit declaration of what's on the knife repo. They get really big and now, instead of having a convenient abstraction that packages those concepts together, you now have to trust that yes, those explicitly-declared inputs are all the same.

Changing this stuff for the ChefZero artifacts won't be too hairy. However, changing it for what goes into the chef repo will mean separate declarations for:

````
file 'cookbooks/x' # ...
````

and

````
file 'cookbooks/x-1.0.0' # ...
````

Repeated in a lot of places. I abstracted that out in the first place because I found myself testing a lot of stuff like that.

It also warped the structure of the context. Since you are explicitly declaring things, you tend to start caring about conserving how often you explicitly declare stuff. So the original tests had things like, 

````
context "with one of each thing in the knife repository" do
  context "except this one change in roles " do
    # ....
  end
end
````

Which I found a lot more difficult to reason about (both for the code and the stated intention documented by ````context````). This was clearer to me, and easier to work with when testing cookbook directories with and without version numbers:

````
context "with one of each thing in the knife repository" do
  # ...
end

context "with a different role in the knife repository" do
  # ...
end
````

I can change it all back. If I change it back to the nested version, I will have to fiddle with how the cookbook files get setup, since for the versioned cookbook tests, we'd have to have versioned cookbook names. Alternatively, I can get it back to the nested version, and then copy the whole thing and make versioned cookbook completely separate.