Testing framework and data

[sumnerwarren]

There are test xml files for 12-13 with days=1 to 12-13 with days=7 for both feed=all and feed=undergrad. This should give us a good amount of data to start with. At this point, I've created a Cakefile which will map the xml files into the resulting json files that we want, and I've created all of the result files for all 20 of the current tests in test/posts.coffee. These test different ways to fetch "today", as well as ranges and retrieving specific posts by id.

The server is set up to do some very simple request handling. Right now, requests come in, a test xml file is loaded and it's translated to json, but not the way it should be, so none of the tests are passing right now. The xml parsing code in the Cakefile can be used as a starting point for implementing the xml to json translation.

[jonahkagan]

I'm a little worried that if we just use the same code in Cakefile to implement the transformation, then we'll be using the same code to generate both test results and actual results, so we won't be testing anything. Not sure how to get around this, but maybe we should handwrite some small test cases? Or maybe we should ignore the code in the Cakefile when writing the real transformation?

[sumnerwarren]

Yea, I realized that this morning too. I think it makes more sense to write the real transformations in a different way. The Cakefile uses sax and events which gives us finer control over the translation to json. I think in production we might just want to translate the xml straight to json without any special rules and then perform all the manipulation on the json and return that.

[sumnerwarren]

And I get like your comment about getToday and switching on then env. Are you suggesting we move the actual function definitions into the when blocks, or just perform assignments to other functions like we are now for fetchres?

[jonahkagan]

I was thinking of moving the actual definitions into the when blocks, which would be a bit annoying since then you'd have to declare those identifiers first to get them into the proper scope (although I'm not actually sure about coffeescript's scoping rules for switch).

We could also just do it the fetchres way, but make sure to group all of those configured functions together in the source.

A third option would be to declare all the test versions in a separate module and then have one config when block that rebinds the identifiers for those functions. Like so:

switch process.env.NODE_ENV
  when "development", "test"
    t = require "test-funs"
    getToday = t.getToday
    fetchRes = t.fetchRes

I kind of like this last approach because it's the least invasive in the actual codebase even though it does have a bit more typing overhead.

[sumnerwarren]

I like the last approach the best too. I don't think there's any reason why all the test functionality should be inside the server when it's completely separate.

[jonahkagan]

Oops, I didn't see these new commits! I thought you were still working on it. Let me know next time I'm slow.

[jonahkagan]

@jswarren do you want to delete this branch?