Property-based testing is interesting; we can use type annotations to write neato tests. Here's one where the test framework could generate examples, perhaps without us thinking about canned examples. For example, what about really long names?

var RequestSchema = {
    "title": "Example Schema",
    "type": "object",
    "properties": {
        "firstName": {
            "type": "string"
        },
        "lastName": {
            "type": "string"
        }
    },
    "required": ["firstName", "lastName"]
};
var handler = (Schema:RequestSchema request) -> {

}

describe:  'request handler' -> {
  it 'stores the first and last name in the datastore' -> {
   request = schemaedRequest(RequestSchema, {
  firstName: FirstName, lastName: LastName
});  // destructuring to capture randomly generated value for FirstName and LastName based on type info from schema
  handler(request);
 expect(dataStore.last().firstName).toEqual(FirstName);
 expect(dataStore.last().lastName).toEqual(LastName);
  }
}

I have a nagging feeling that this quickcheck-style stuff is cool and has potential but that additional idioms would be needed for testing other behavior. For example, ordering: "This is some code that should render for the first time after these three requests complete, then it should render again when new values for any of these three streams arrive"

commatize = (string s, string y) -> { "{s}, {y}" };

"hello" |            // "hello" piped into
  commatize(y:"world")     // a partial application of commatize

should a partial application look like a function call with missing arguments? (means you have to know the number of parameters to know if it's a function call or not, unless the environment knows types)

maybe:

"hello" |
  commatize(x:_, y:"world)

Immutable values are a great convenience, but they make it hard to talk about persistent entities whose state changes over time, like users whose home addresses might change from time to time. Based on Rich Hickey's work, and also the pretty-slick http API for FireBase (where you make an initial request for a resource at a path and are subscribed to updates via websocket/polling), the proposal for this language is treating entities as streams of data.

@user = http.subscribe('users/1')
@posts = http.subscribe('users/1/posts')


all(@user, @posts, (user, posts) -> { 
   <h2>{{user.name}}</h2>
  <h3>current stats: {{user.status}} </h3>
<ul>
  {{each post in posts}}
  <li>{{post.text}}

</li>
{{/each}}
</ul>
}

Dependency Test Case Dovetailing

When testing a unit of code that depends on another unit of code, there are broadly two options-- using a test double to simulate the real dependency, or using the real dependency. Sometimes one is more easy than the other, and sometimes one is easier to reason about than the other. Both can be complex, as there is setup involved in configuring the real dependency or in defining the behavior of the fake.

Let's assume we have a persister, and we want to write a requestHandler that tries to persist and returns the correct HTTP status based on what the persister does.

Imagine the persister itself has 3 test cases:

1. given a working database connection, it inserts a row into a SQL database and returns a tuple that includes the new ID of that item.

2. given a non-working database connection, returns a Failed token

var persister = function() {
Either<Tuple<int,TodoItem>, Failed>this.persist(TodoItem item) {
};

}

Our persister has two cases that we know about. Our requestHandler should define test cases that cover both of these outputs. In fact, we may want to cover the cross-product of all cases for all the dependencies we produce.

• drawbacks: if you practice outside-in development, you typically define the behavior of the inner dependencies last. There may not be a real drawback here; you would typically stash the outer layer, develop the inner layer, commit, and then pop the stash.