Integration tests

[RocketPuppy]

There are some nice, mostly auto-generated sanity tests already, but I've put off some of the more higher level integration and "happy-path" tests while exploring the design and implementation.

Some things to test:

• [ ] Authentication. These tests should specify which routes are covered by which authentication strategies.
• [ ] Authorization. These tests should make sure Answerers and Questioners can only access the session they're authorized for, and that sessions can only be accessed by a single Answerer.
• [ ] Websockets. These tests should cover the messaging system. When an action is taken (an endpoint is hit), all connected websocket clients should receive the appropriate message.
• [ ] Endpoints. Each endpoint should have its logic specified and tested.

[RocketPuppy]

I should also clarify that many tests are not necessary because of the guarantees provided by the type system and the existing libraries (would you test Rails?). Specifically in the above, I'm actually thinking that tests for Authentication are not actually necessary. The tests would be testing two things: 1) that certain routes are covered by certain authentication strategies, 2) that those authentication strategies either authenticate or do not. Number 1 (and some of number 2) is entirely covered by the type system and the way servant works. If a route says AuthProtect "questioner-auth" then that's all that's necessary for the route to be protected. Number 2 is covered by the library implementations (and some of the type system). AuthProtect "questioner-auth" is defined to return a QuestionerId, and a route handler protected by that must accept a QuestionerId. The library handles the parsing and decrypting of the authentication cookie, so there's also no need to test that.

[RocketPuppy]

I've been looking at refactoring to a free monad based approach to make testing easier. See dw/free-monads for the work in progress on this. The goal being to enable the definition of one or multiple DSLs with a pure, semantic-defining intepreter, and the layering of other interpreters on top of it that add other semantics or transform the implementation. This would allow testing to proceed as follows:

1. Test (or prove) that the pure interpreter has the desired semantics.
2. Test (or prove) that the layered interpreters preserve the desired semantics.
3. Test (or prove) that combining interpreters and DSLs has the desired semantics.

The problem at the moment is defining an appropriate DSL or set of DSLs.

See: http://degoes.net/articles/modern-fp-part-2