title: Keeping client state when an api with mocha
body: <p>My api can be asked to create an object, then later asked to update that same object, so my test file does this...</p>
  
  <pre><code>var foobarId;  // this might be a mistake
  
  it("should create a single foobar", function(done) {
      server
          .post("/foobar?key=value")
          .expect("Content-type", /json/)
          .expect(200)
          .end(function(err, res) {
              res.status.should.equal(200);
              res.body.should.have.property('key', 'value');
              foobarId = res.body._id;
          done();
      });
  });
  
  it("should return a foobar when I get one", function(done) {
      server
          .get("/foobar/" + foobarId)
          .expect("Content-type", /json/)
          .expect(200)
          .end(function(err, res) {
              res.status.should.equal(200);
              res.body.should.have.property('key', 'value');
          done();
      });
  });
  </code></pre>
  
  <p>So is this wrong what I'm trying here?  (1) as I get more logic into the test, I risk creating logic errors in the test and needing a test for my test.  (2) when the create fails, my console output gets ugly... first, the assertion error that I expect and need telling me the test failed, but then ugly traceback stuff, I think, because <code>foobarId</code> is undefined.</p>
  
  <p>The ugliness makes me think that the good people at mocha (or supertest or wherever) didn't expect me to do what I'm doing.</p>
  
  <p>Is there a right way to write this kind of test?</p>