elli_test's limitations should be documented

[drfloob]

I think elli_test is a valuable tool, but it could be a lot clearer what its use cases and limitations are. These hurdles should be documented to save folks time.

For instance, middleware like elli_date doesn't work if you use elli_test:call more than once, since the elli_startup event is signaled more than once, and elli_date's elli_startup handler is not idempotent (it tries and fails to instantiate ets twice).

Since elli_test:call calls the handler method directly, the returned Body list is not flattened (as shown in the hello iolist example). Tests need to match the handler's exact output rather than what you'd expect to receive through a full request to the running server.

Along the same lines, tests can only check against the headers set directly in the handler, and not any additional headers you'd expect from a full request.

Maybe these bits are obvious to others, but I spent some time figuring out elli_test was not a drop-in replacement for setting up and tearing down the server (as shown in elli's own test suite).

[knutin]

Hi. Thanks for good input.

I just pushed a new version of elli_date that works together with elli_test.

At the moment, elli_test is simply a helper for calling your callback. With some changes to elli_http it could allow testing the whole response-generating machinery including the parts inside Elli. This would be very interesting and maybe also useful. I've paid attention to how iolists are handled within Elli to explicitly avoid flattening them if not necessary as this can be done inside the network driver. The test wrapper could flatten the response and also hide any Elli internal APIs.

I will keep this change in mind. It is quite intrusive, so I don't want to jump in without having thought it through.

For now, I have added some more documentation to the elli_test module, I hope that makes it clearer.