Feature/chain

[ammario]

Resolves #11 Resolves #10 Resolves #7 Resolves #5 Resolves #3

[ammario]

@nhooyr one of my objectives with this package is to support declarative test generation. For example, we could send a long HTTP request into a function like requirePermissions(granter, grantee, permission, *hat.Response and requirePermission would subtests with accounts with varying permissions.

[ammario]

@nhooyr are you suggesting we port over Testify's?

[ammario]

Their assertions are structured dramatically differently than what hat wants.

[ammario]

@nhooyr made DuplicateBody apart of T

[nhooyr]

I think it'd be worth being able to create a request with options and whatnot but not actually running it. You could then run it in subtests with different options for each subtest. Thoughts?

[ammario]

What advantage does that have over Again?

I didn't go down that route to avoid an explicit Send(t). or Do(t) call on the chain.

[nhooyr]

You don't have to send the initial request and get a response back in the top level test. Like in the example, you could create the initial test in the top level test, then create two subtests, success and failure where you actually send the request.

[ammario]

Do you think it's worth losing the ability to chain Again?

[nhooyr]

Not sure. Why don't you want a Send(t) or a Do(t) btw? That would make this all really easy and composable.

[ammario]

I went down that route looking for a framework to implement test generation, but I think it will be possible with Send/Do too

[nytopop]

The typical approach in functional languages is to separate composition from execution - then composition can be made much more powerful / able to use datastructures of functions or whatever that can be executed as a single recursive unit.

I'm good with either approach, but mixing the two makes things confusing fast.

[ammario]

Working on that approach right now.

[nhooyr]

If we go the Send/Do route, its probably better to just chain everything then.

[ammario]

One challenge is copying an HTTP request reliably. The nice way to do it is treating the HTTP request like a FSM and creating a copy of it by applying all the transformations.

If one of the transformations fails a testing.T outside of our current test function, the obscure executed panic(nil) or runtime.Goexit will propagate.

[ammario]

This problem effects both approaches

[ammario]

@nhooyr

We don't want to chain request building or response assertions since we want the API's consumers to be able to use their own.

[ammario]

I'll just make ResponseAssertion and RequestOption accept the T

[ammario]

86cedc84080d7dd181536a864cfe78bf96296672 does this

I do agree this is better design, but all the hat.Ts are unfortunate