I rewrote the mime type and provides specs we were looking at yesterday morning to show you the kind of thing I think you should be producing. The main things:
As few expectations per test as possible. Preferably one. Here the extra overhead for one-expectation per test wasn't really worth it: it's a tradeoff...
grouping definitely related tests into contexts. Here, you could even think about breaking the three-action Sinatra app in L126-135 into three apps, one in each of the relevant contexts
Explanatory names for tests. If you don't understand what it's doing well enough to name it then google it - read the sinatra docs, read the HTTP spec, ask me or Konstantin...
Add as little noise to the tests as possible. Most of the time the app.call 'REQUEST_METHOD' => 'GET', 'PATH_INFO' => '/', 'HTTP_ACCEPT' => 'application/xml', 'rack.input' => '' syntax is just adding noise to your tests, especially if all it's doing is the equivalent of get '/foo'
I rewrote the mime type and provides specs we were looking at yesterday morning to show you the kind of thing I think you should be producing. The main things:
app.call 'REQUEST_METHOD' => 'GET', 'PATH_INFO' => '/', 'HTTP_ACCEPT' => 'application/xml', 'rack.input' => ''syntax is just adding noise to your tests, especially if all it's doing is the equivalent of get '/foo'