Support optional return values

[vlucas]

Support optional return values

[vlucas]

This is an interesting use-case, but strikes me as bad API design. Since I see a _id field in the response that is a String, I assume these values are coming straight out of MongoDB, and the schema changes over time are the source of these fields that may or may not be present in the API output. It is generally a good idea to stabilize the API output for your users (consumers of your API) so that it is always consistent. One of the things testing your API output with a tool like Frisby.js does is reveal these idiosyncrasies, so they can be corrected. I would recommend that instead of dumping these values directly from MongoDB and accounting for these fields that may or may not be present in every client that consumes your API, you merge the MongoDB output with a field mapping that always provides all fields in a consistent manner, with null values if the document does not contain the field. This way, the API clients don't have to code around differences in responses from your API and you can increase the reliability of your API and reduce errors in clients that consume it.

[Siyfion]

I can see your point in this particular instance, but in another part of my application I have a collection of Products which all clients store their product data in. So it may contain a shoe, with properties like size, gender, price, but it may also contain a sandwich with properties like ingredients and filling.
When a client requests a product back, they need to look at the object to see what properties it has.

I guess I couldn't ever hope to test this particular scenario in the API however, so perhaps I've just answered my own question!?

[vlucas]

I see. This to me is the much more interesting and valid use-case. It seems like what you need is custom branching logic that runs specific JSON property tests depending on the value of another JSON property. So in your case, the Product may have a type: "shoe" in which case a certain set of other JSON keys would need to be tested for (size, gender, etc.). You can achieve this with a switch statement in a custom afterJSON callback right now, or you can propose a new Frisby.js matcher that would achieve this. I'm open for ideas. Do you have any pseudo code in mind?

[Siyfion]

The use-case I describe is, by it's very nature, using the schema-less design of a MongoDB collection to allow users to store essentially anything that they can thing up in the Products collection, so I can't see how it ever could be tested other than by testing only required fields that a product must have, ie. _id

[Siyfion]

Simply me being silly.

[vlucas]

Actually I think the use-case is valid and can be tested with Frisby:

frisby.create('Ensure product types are have all keys')
  .get(base_url + '/products.json')
  // All common types
  .expectJSONTypes('*', {
    _id: String,
    price: Number
  })
  .afterJSON(function(json) {
    json.items.forEach(function(item, key) {
      // Type swich
      switch(item.type) {
        // Shoes
        case 'shoe':
          expect(item).toContainJSONTypes({
            size: Number,
            Gender: String
          });          
        break;
        // Sandwiches
        case 'sandwich':
          expect(item).toContainJSONTypes({
            ingredients: Array,
            filling: String
          });
        break;
      }
    });
  })
.toss();

It's a lot more work this way, but you could extract all these assertions into your own Jasmine matchers or objects of product types to test, etc. to make it easier and a little less verbose.