Assert for HTTP Headers

[falkerson]

Assert package has 2 useful method to verify HTTP status - https://godoc.org/github.com/stretchr/testify/assert#HTTPSuccess and body - https://godoc.org/github.com/stretchr/testify/assert#HTTPBodyContains . It will be nice also to add method to verify HTTP headers.

[devdinu]

@falkerson Agreed, You could raise a PR. Share the func signature you think gonna be useful, so we could get comments.

[falkerson]

@devdinu pls take a look #601

[devdinu]

I've been thinking an alternate or a function which takes request, coz these functions doesn't accept body too.

Also for each type of extraction we've to keep exposing a function. Rather

r, err := http.NewRequest(method, url, body)
resp, err := assert.HTTPSuccess(r)
assert.Equal(t, "some-data", resp.Body.String())
assert.True(t, resp.Header.Contains("key", "val"))
...

it would be a new set of functions, probably others could comment, because i haven't used much of HTTP functions, as i write those custom. These function has more params and feels like just a wrapper around making request and parsing or reading headers (which could be done by a struct).

[mattgen88]

The usefulness of the HTTP functions seems to fall a bit short. If your handler requires reading headers, they won't work for you. If you need to send something in the body, same problem.

[KrzysztofMadejski]

The project I'm working on have quite a lot of tests for http handlers. I was thinking as well to create an abstraction layer to make tests definitions simpler. What do you think about below approach?

func TestListJobs_CreatJob(t *testing.T) {
  // on the first line we define what we call
  t.Run("List: no jobs", call(ListJobsHandler()).GET("/jobs?sort=-date")
  // then what we expect
	.Assert().Status(httpStatusOK).ContentType("application/json").Header("Allow-Origin: *").JsonBody(`[]`)).JsonConformsTo([]*models.Job)

  // similarly for a POST 
  t.Run("POST a job", call(CreateJobHandler()).POST("/jobs").JsonBody(`{}`).SetContextValue(UsernameKey, username)
	.Assert() // etc
  )
}

So I guess the addition would be to allow chaining to offer more flexibility to create request and not to repeat code, and also to add new methods for checking results.

UPDATE: I moved my comment to a new issue #809

[KrzysztofMadejski]

I'm working on my proposition here: https://github.com/KrzysztofMadejski/testify-handlers

[KrzysztofMadejski]

@mattgen88 @falkerson @devdinu You could try my lib for testing http handlers: https://gitlab.com/gotests/handlertest

[Matovidlo]

@devdinu Would it be good idea that I create PR to support override of HTTP headers and HTTP body which is not supported?

I would like to use only this library to test HTTP handlers and do not include n testing frameworks for n purposes.