Re: [go-nuts] ResponseRecorder HTTP status code defaults to 200

['Axel Wagner' via golang-nuts]

It is not "meant for tests internal to the http package". It's meant for
tests of users of the `net/http` package. That is, implementations of the
`http.Handler` interface.
In the context of the standard library, that is what "general purpose HTTP
testing" means.

On Tue, Oct 17, 2023 at 10:44 AM Simon Walter  wrote:

> It is good practice to use test lang/tools/libs/etc different from what
> you are using in your actual code.
>
> If the author has meant for the httptest package as general purpose HTTP
> testing library, then, I will argue that such defaults are incorrect. It is
> incorrect even if the intended purpose is to tests code that is derived
> from http package.
>
> If the author has meant for the httptest package to be used for tests
> internal to the http package, then it should be labeled such.
>
> I'll mention this to bradf...@golang.org.
> On Monday, October 16, 2023 at 4:58:16 PM UTC+2 Axel Wagner wrote:
>
>> To be clear: The behavior of an `http.ResponseWriter` to implicitly use a
>> 200 status code if no explicit WriteHeader call is made is documented:
>> https://pkg.go.dev/net/http#ResponseWriter.WriteHeader
>> I really think it is a bad (or at least strange) idea to claim to
>> implement `http.ResponseWriter` while *not* replicating this behavior.
>>
>> On Mon, Oct 16, 2023 at 4:53 PM Axel Wagner 
>> wrote:
>>
>>> It seems to me that the fact that the functions accept and return types
>>> from `net/http` (like `http.ResponseWriter` and `http.Handler`) and given
>>> that it's nested below `net/http` should make it fairly obvious that it's
>>> meant to be used with `net/http`. I also genuinely don't understand what
>>> the intersection is of "being tempted to use `httptest`" and "does not
>>> intend to be used with `net/http`". I also genuinely don't understand how
>>> the behavior of `httptest` could ever cause any harm (quite the opposite).
>>>
>>> But, YMMV, of course and you are free to roll your own testing helpers.
>>>
>>> On Mon, Oct 16, 2023 at 9:30 AM Simon Walter  wrote:
>>>
 Axel, thanks for providing some context.

 I suppose it is better for me to think of the httptest package as
 specific to the http package - although this is not explicitly stated:
 "Package httptest provides utilities for HTTP testing"

 This seems misleading as is the case with this '200' default.

 I stopped using httptest.NewRecorder() because of the possibility to
 introduce changes to tests that would make tests pass. Not everyone knows
 the internals of all the code. Because of this, I think it is risky to have
 values set by default to the value that causes the test to pass.

 Some questions that should not keep us awake at night: The test passed,
 but will it fail? Will it fail where/how I think it will?

 Simon

 On Monday, October 16, 2023 at 6:16:41 AM UTC+2 Axel Wagner wrote:

> If you want to argue that `net/http` should not set the response code
> to 200 by default, I would be inclined to agree. I don't particularly like
> that the API even *allows* you not to explicitly set a response code. But
> it does. And while it does, the best test is one that matches the behavior
> of the production environment as closely as possible, full stop.
>
> Another way to look at it: Why do you believe you have to test that
> your handler sets the response code to 200? Why should the test fail, if 
> it
> doesn't do it - given that *the production code* will still end up with 
> the
> right response code? If the response sent to the user is the right one -
> why would it matter whether it was your Handler that set it, or the
> framework?
>
> On Sun, Oct 15, 2023 at 10:22 PM Simon Walter 
> wrote:
>
>> How does that explain why it is a good idea?
>>
>> Perhaps my concern is not clear enough.
>>
>> For example:
>>
>> n := 5
>> funcThatShouldSetNtoFive()
>> if n != 5 {
>>   panic("n is not 5)
>> }
>>
>> This is not a good test.
>>
>> I can check if the value has changed by:
>>
>> n := 0
>> funcThatShouldSetNtoFive()
>> if n != 5 {
>>   panic("n is not 5)
>> }
>>
>> That's a bit more sensible.
>>
>> Wouldn't it be less risky for a test to fail by default? Removal of
>> the call to funcThatShouldSetNtoFive, IMO, should result in failure.
>>
>> On Sunday, October 15, 2023 at 6:10:36 PM UTC+2 Axel Wagner wrote:
>>
>>> A default `net/http` server also uses 200 as the default response
>>> code. The behavior of an `http.Handler` not setting a response code 
>>> should
>>> be the same, if it uses `httptest`, as if it uses `net/http`.
>>>
>>> On Sun, Oct 15, 2023 at 5:17 PM Simon Walter 
>>> wrote:
>>>
 Hi all,

 What is the reason that ResponseRecorder HTTP status code defaults
 to 200?

Re: [go-nuts] ResponseRecorder HTTP status code defaults to 200

[Simon Walter]

And so: https://github.com/golang/go/issues/63589

On Tuesday, October 17, 2023 at 10:44:04 AM UTC+2 Simon Walter wrote:

> It is good practice to use test lang/tools/libs/etc different from what 
> you are using in your actual code.
>
> If the author has meant for the httptest package as general purpose HTTP 
> testing library, then, I will argue that such defaults are incorrect. It is 
> incorrect even if the intended purpose is to tests code that is derived 
> from http package.
>
> If the author has meant for the httptest package to be used for tests 
> internal to the http package, then it should be labeled such.
>
> I'll mention this to brad...@golang.org.
> On Monday, October 16, 2023 at 4:58:16 PM UTC+2 Axel Wagner wrote:
>
>> To be clear: The behavior of an `http.ResponseWriter` to implicitly use a 
>> 200 status code if no explicit WriteHeader call is made is documented:
>> https://pkg.go.dev/net/http#ResponseWriter.WriteHeader
>> I really think it is a bad (or at least strange) idea to claim to 
>> implement `http.ResponseWriter` while *not* replicating this behavior.
>>
>> On Mon, Oct 16, 2023 at 4:53 PM Axel Wagner  
>> wrote:
>>
>>> It seems to me that the fact that the functions accept and return types 
>>> from `net/http` (like `http.ResponseWriter` and `http.Handler`) and given 
>>> that it's nested below `net/http` should make it fairly obvious that it's 
>>> meant to be used with `net/http`. I also genuinely don't understand what 
>>> the intersection is of "being tempted to use `httptest`" and "does not 
>>> intend to be used with `net/http`". I also genuinely don't understand how 
>>> the behavior of `httptest` could ever cause any harm (quite the opposite).
>>>
>>> But, YMMV, of course and you are free to roll your own testing helpers.
>>>
>>> On Mon, Oct 16, 2023 at 9:30 AM Simon Walter  wrote:
>>>
 Axel, thanks for providing some context.

 I suppose it is better for me to think of the httptest package as 
 specific to the http package - although this is not explicitly stated: 
 "Package httptest provides utilities for HTTP testing"

 This seems misleading as is the case with this '200' default.

 I stopped using httptest.NewRecorder() because of the possibility to 
 introduce changes to tests that would make tests pass. Not everyone knows 
 the internals of all the code. Because of this, I think it is risky to 
 have 
 values set by default to the value that causes the test to pass.

 Some questions that should not keep us awake at night: The test passed, 
 but will it fail? Will it fail where/how I think it will?

 Simon

 On Monday, October 16, 2023 at 6:16:41 AM UTC+2 Axel Wagner wrote:

> If you want to argue that `net/http` should not set the response code 
> to 200 by default, I would be inclined to agree. I don't particularly 
> like 
> that the API even *allows* you not to explicitly set a response code. But 
> it does. And while it does, the best test is one that matches the 
> behavior 
> of the production environment as closely as possible, full stop.
>
> Another way to look at it: Why do you believe you have to test that 
> your handler sets the response code to 200? Why should the test fail, if 
> it 
> doesn't do it - given that *the production code* will still end up with 
> the 
> right response code? If the response sent to the user is the right one - 
> why would it matter whether it was your Handler that set it, or the 
> framework?
>
> On Sun, Oct 15, 2023 at 10:22 PM Simon Walter  
> wrote:
>
>> How does that explain why it is a good idea?
>>
>> Perhaps my concern is not clear enough.
>>
>> For example:
>>
>> n := 5
>> funcThatShouldSetNtoFive()
>> if n != 5 {
>>   panic("n is not 5)
>> }
>>
>> This is not a good test.
>>
>> I can check if the value has changed by:
>>
>> n := 0
>> funcThatShouldSetNtoFive()
>> if n != 5 {
>>   panic("n is not 5)
>> }
>>
>> That's a bit more sensible.
>>
>> Wouldn't it be less risky for a test to fail by default? Removal of 
>> the call to funcThatShouldSetNtoFive, IMO, should result in failure.
>>
>> On Sunday, October 15, 2023 at 6:10:36 PM UTC+2 Axel Wagner wrote:
>>
>>> A default `net/http` server also uses 200 as the default response 
>>> code. The behavior of an `http.Handler` not setting a response code 
>>> should 
>>> be the same, if it uses `httptest`, as if it uses `net/http`.
>>>
>>> On Sun, Oct 15, 2023 at 5:17 PM Simon Walter  
>>> wrote:
>>>
 Hi all,

 What is the reason that ResponseRecorder HTTP status code defaults 
 to 200?


 

Re: [go-nuts] ResponseRecorder HTTP status code defaults to 200

[Simon Walter]

It is good practice to use test lang/tools/libs/etc different from what you 
are using in your actual code.

If the author has meant for the httptest package as general purpose HTTP 
testing library, then, I will argue that such defaults are incorrect. It is 
incorrect even if the intended purpose is to tests code that is derived 
from http package.

If the author has meant for the httptest package to be used for tests 
internal to the http package, then it should be labeled such.

I'll mention this to bradf...@golang.org.
On Monday, October 16, 2023 at 4:58:16 PM UTC+2 Axel Wagner wrote:

> To be clear: The behavior of an `http.ResponseWriter` to implicitly use a 
> 200 status code if no explicit WriteHeader call is made is documented:
> https://pkg.go.dev/net/http#ResponseWriter.WriteHeader
> I really think it is a bad (or at least strange) idea to claim to 
> implement `http.ResponseWriter` while *not* replicating this behavior.
>
> On Mon, Oct 16, 2023 at 4:53 PM Axel Wagner  
> wrote:
>
>> It seems to me that the fact that the functions accept and return types 
>> from `net/http` (like `http.ResponseWriter` and `http.Handler`) and given 
>> that it's nested below `net/http` should make it fairly obvious that it's 
>> meant to be used with `net/http`. I also genuinely don't understand what 
>> the intersection is of "being tempted to use `httptest`" and "does not 
>> intend to be used with `net/http`". I also genuinely don't understand how 
>> the behavior of `httptest` could ever cause any harm (quite the opposite).
>>
>> But, YMMV, of course and you are free to roll your own testing helpers.
>>
>> On Mon, Oct 16, 2023 at 9:30 AM Simon Walter  wrote:
>>
>>> Axel, thanks for providing some context.
>>>
>>> I suppose it is better for me to think of the httptest package as 
>>> specific to the http package - although this is not explicitly stated: 
>>> "Package httptest provides utilities for HTTP testing"
>>>
>>> This seems misleading as is the case with this '200' default.
>>>
>>> I stopped using httptest.NewRecorder() because of the possibility to 
>>> introduce changes to tests that would make tests pass. Not everyone knows 
>>> the internals of all the code. Because of this, I think it is risky to have 
>>> values set by default to the value that causes the test to pass.
>>>
>>> Some questions that should not keep us awake at night: The test passed, 
>>> but will it fail? Will it fail where/how I think it will?
>>>
>>> Simon
>>>
>>> On Monday, October 16, 2023 at 6:16:41 AM UTC+2 Axel Wagner wrote:
>>>
 If you want to argue that `net/http` should not set the response code 
 to 200 by default, I would be inclined to agree. I don't particularly like 
 that the API even *allows* you not to explicitly set a response code. But 
 it does. And while it does, the best test is one that matches the behavior 
 of the production environment as closely as possible, full stop.

 Another way to look at it: Why do you believe you have to test that 
 your handler sets the response code to 200? Why should the test fail, if 
 it 
 doesn't do it - given that *the production code* will still end up with 
 the 
 right response code? If the response sent to the user is the right one - 
 why would it matter whether it was your Handler that set it, or the 
 framework?

 On Sun, Oct 15, 2023 at 10:22 PM Simon Walter  
 wrote:

> How does that explain why it is a good idea?
>
> Perhaps my concern is not clear enough.
>
> For example:
>
> n := 5
> funcThatShouldSetNtoFive()
> if n != 5 {
>   panic("n is not 5)
> }
>
> This is not a good test.
>
> I can check if the value has changed by:
>
> n := 0
> funcThatShouldSetNtoFive()
> if n != 5 {
>   panic("n is not 5)
> }
>
> That's a bit more sensible.
>
> Wouldn't it be less risky for a test to fail by default? Removal of 
> the call to funcThatShouldSetNtoFive, IMO, should result in failure.
>
> On Sunday, October 15, 2023 at 6:10:36 PM UTC+2 Axel Wagner wrote:
>
>> A default `net/http` server also uses 200 as the default response 
>> code. The behavior of an `http.Handler` not setting a response code 
>> should 
>> be the same, if it uses `httptest`, as if it uses `net/http`.
>>
>> On Sun, Oct 15, 2023 at 5:17 PM Simon Walter  
>> wrote:
>>
>>> Hi all,
>>>
>>> What is the reason that ResponseRecorder HTTP status code defaults 
>>> to 200?
>>>
>>>
>>> https://cs.opensource.google/go/go/+/refs/tags/go1.21.3:src/net/http/httptest/recorder.go;drc=ff14e844d26090e09aa335d836f737c09a7a0402;l=55
>>>
>>>
>>> https://cs.opensource.google/go/go/+/refs/tags/go1.21.3:src/net/http/httptest/recorder.go;drc=ff14e844d26090e09aa335d836f737c09a7a0402;l=196
>>>
>>> Can someone explain to me why this is a good idea? Would it not make 

Re: [go-nuts] ResponseRecorder HTTP status code defaults to 200

['Axel Wagner' via golang-nuts]

To be clear: The behavior of an `http.ResponseWriter` to implicitly use a
200 status code if no explicit WriteHeader call is made is documented:
https://pkg.go.dev/net/http#ResponseWriter.WriteHeader
I really think it is a bad (or at least strange) idea to claim to implement
`http.ResponseWriter` while *not* replicating this behavior.

On Mon, Oct 16, 2023 at 4:53 PM Axel Wagner 
wrote:

> It seems to me that the fact that the functions accept and return types
> from `net/http` (like `http.ResponseWriter` and `http.Handler`) and given
> that it's nested below `net/http` should make it fairly obvious that it's
> meant to be used with `net/http`. I also genuinely don't understand what
> the intersection is of "being tempted to use `httptest`" and "does not
> intend to be used with `net/http`". I also genuinely don't understand how
> the behavior of `httptest` could ever cause any harm (quite the opposite).
>
> But, YMMV, of course and you are free to roll your own testing helpers.
>
> On Mon, Oct 16, 2023 at 9:30 AM Simon Walter  wrote:
>
>> Axel, thanks for providing some context.
>>
>> I suppose it is better for me to think of the httptest package as
>> specific to the http package - although this is not explicitly stated:
>> "Package httptest provides utilities for HTTP testing"
>>
>> This seems misleading as is the case with this '200' default.
>>
>> I stopped using httptest.NewRecorder() because of the possibility to
>> introduce changes to tests that would make tests pass. Not everyone knows
>> the internals of all the code. Because of this, I think it is risky to have
>> values set by default to the value that causes the test to pass.
>>
>> Some questions that should not keep us awake at night: The test passed,
>> but will it fail? Will it fail where/how I think it will?
>>
>> Simon
>>
>> On Monday, October 16, 2023 at 6:16:41 AM UTC+2 Axel Wagner wrote:
>>
>>> If you want to argue that `net/http` should not set the response code to
>>> 200 by default, I would be inclined to agree. I don't particularly like
>>> that the API even *allows* you not to explicitly set a response code. But
>>> it does. And while it does, the best test is one that matches the behavior
>>> of the production environment as closely as possible, full stop.
>>>
>>> Another way to look at it: Why do you believe you have to test that your
>>> handler sets the response code to 200? Why should the test fail, if it
>>> doesn't do it - given that *the production code* will still end up with the
>>> right response code? If the response sent to the user is the right one -
>>> why would it matter whether it was your Handler that set it, or the
>>> framework?
>>>
>>> On Sun, Oct 15, 2023 at 10:22 PM Simon Walter 
>>> wrote:
>>>
 How does that explain why it is a good idea?

 Perhaps my concern is not clear enough.

 For example:

 n := 5
 funcThatShouldSetNtoFive()
 if n != 5 {
   panic("n is not 5)
 }

 This is not a good test.

 I can check if the value has changed by:

 n := 0
 funcThatShouldSetNtoFive()
 if n != 5 {
   panic("n is not 5)
 }

 That's a bit more sensible.

 Wouldn't it be less risky for a test to fail by default? Removal of the
 call to funcThatShouldSetNtoFive, IMO, should result in failure.

 On Sunday, October 15, 2023 at 6:10:36 PM UTC+2 Axel Wagner wrote:

> A default `net/http` server also uses 200 as the default response
> code. The behavior of an `http.Handler` not setting a response code should
> be the same, if it uses `httptest`, as if it uses `net/http`.
>
> On Sun, Oct 15, 2023 at 5:17 PM Simon Walter 
> wrote:
>
>> Hi all,
>>
>> What is the reason that ResponseRecorder HTTP status code defaults to
>> 200?
>>
>>
>> https://cs.opensource.google/go/go/+/refs/tags/go1.21.3:src/net/http/httptest/recorder.go;drc=ff14e844d26090e09aa335d836f737c09a7a0402;l=55
>>
>>
>> https://cs.opensource.google/go/go/+/refs/tags/go1.21.3:src/net/http/httptest/recorder.go;drc=ff14e844d26090e09aa335d836f737c09a7a0402;l=196
>>
>> Can someone explain to me why this is a good idea? Would it not make
>> more sense to set it to a value that is not a valid HTTP response code 
>> such
>> as 0?
>>
>> Simon
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it,
>> send an email to golang-nuts...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/golang-nuts/321a84fa-3aeb-4f3a-ba4f-a05e797652d6n%40googlegroups.com
>> 
>> .
>>
> --
 You received this message because you are 

Re: [go-nuts] ResponseRecorder HTTP status code defaults to 200

['Axel Wagner' via golang-nuts]

It seems to me that the fact that the functions accept and return types
from `net/http` (like `http.ResponseWriter` and `http.Handler`) and given
that it's nested below `net/http` should make it fairly obvious that it's
meant to be used with `net/http`. I also genuinely don't understand what
the intersection is of "being tempted to use `httptest`" and "does not
intend to be used with `net/http`". I also genuinely don't understand how
the behavior of `httptest` could ever cause any harm (quite the opposite).

But, YMMV, of course and you are free to roll your own testing helpers.

On Mon, Oct 16, 2023 at 9:30 AM Simon Walter  wrote:

> Axel, thanks for providing some context.
>
> I suppose it is better for me to think of the httptest package as specific
> to the http package - although this is not explicitly stated: "Package
> httptest provides utilities for HTTP testing"
>
> This seems misleading as is the case with this '200' default.
>
> I stopped using httptest.NewRecorder() because of the possibility to
> introduce changes to tests that would make tests pass. Not everyone knows
> the internals of all the code. Because of this, I think it is risky to have
> values set by default to the value that causes the test to pass.
>
> Some questions that should not keep us awake at night: The test passed,
> but will it fail? Will it fail where/how I think it will?
>
> Simon
>
> On Monday, October 16, 2023 at 6:16:41 AM UTC+2 Axel Wagner wrote:
>
>> If you want to argue that `net/http` should not set the response code to
>> 200 by default, I would be inclined to agree. I don't particularly like
>> that the API even *allows* you not to explicitly set a response code. But
>> it does. And while it does, the best test is one that matches the behavior
>> of the production environment as closely as possible, full stop.
>>
>> Another way to look at it: Why do you believe you have to test that your
>> handler sets the response code to 200? Why should the test fail, if it
>> doesn't do it - given that *the production code* will still end up with the
>> right response code? If the response sent to the user is the right one -
>> why would it matter whether it was your Handler that set it, or the
>> framework?
>>
>> On Sun, Oct 15, 2023 at 10:22 PM Simon Walter  wrote:
>>
>>> How does that explain why it is a good idea?
>>>
>>> Perhaps my concern is not clear enough.
>>>
>>> For example:
>>>
>>> n := 5
>>> funcThatShouldSetNtoFive()
>>> if n != 5 {
>>>   panic("n is not 5)
>>> }
>>>
>>> This is not a good test.
>>>
>>> I can check if the value has changed by:
>>>
>>> n := 0
>>> funcThatShouldSetNtoFive()
>>> if n != 5 {
>>>   panic("n is not 5)
>>> }
>>>
>>> That's a bit more sensible.
>>>
>>> Wouldn't it be less risky for a test to fail by default? Removal of the
>>> call to funcThatShouldSetNtoFive, IMO, should result in failure.
>>>
>>> On Sunday, October 15, 2023 at 6:10:36 PM UTC+2 Axel Wagner wrote:
>>>
 A default `net/http` server also uses 200 as the default response code.
 The behavior of an `http.Handler` not setting a response code should be the
 same, if it uses `httptest`, as if it uses `net/http`.

 On Sun, Oct 15, 2023 at 5:17 PM Simon Walter 
 wrote:

> Hi all,
>
> What is the reason that ResponseRecorder HTTP status code defaults to
> 200?
>
>
> https://cs.opensource.google/go/go/+/refs/tags/go1.21.3:src/net/http/httptest/recorder.go;drc=ff14e844d26090e09aa335d836f737c09a7a0402;l=55
>
>
> https://cs.opensource.google/go/go/+/refs/tags/go1.21.3:src/net/http/httptest/recorder.go;drc=ff14e844d26090e09aa335d836f737c09a7a0402;l=196
>
> Can someone explain to me why this is a good idea? Would it not make
> more sense to set it to a value that is not a valid HTTP response code 
> such
> as 0?
>
> Simon
>
> --
> You received this message because you are subscribed to the Google
> Groups "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to golang-nuts...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/321a84fa-3aeb-4f3a-ba4f-a05e797652d6n%40googlegroups.com
> 
> .
>
 --
>>> You received this message because you are subscribed to the Google
>>> Groups "golang-nuts" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to golang-nuts...@googlegroups.com.
>>>
>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/golang-nuts/df053fb7-70bf-483d-afd6-4caee9937aa6n%40googlegroups.com
>>> 
>>> .
>>>
>> --
> You received this message 

Re: [go-nuts] ResponseRecorder HTTP status code defaults to 200

[Simon Walter]

Axel, thanks for providing some context.

I suppose it is better for me to think of the httptest package as specific 
to the http package - although this is not explicitly stated: "Package 
httptest provides utilities for HTTP testing"

This seems misleading as is the case with this '200' default.

I stopped using httptest.NewRecorder() because of the possibility to 
introduce changes to tests that would make tests pass. Not everyone knows 
the internals of all the code. Because of this, I think it is risky to have 
values set by default to the value that causes the test to pass.

Some questions that should not keep us awake at night: The test passed, but 
will it fail? Will it fail where/how I think it will?

Simon

On Monday, October 16, 2023 at 6:16:41 AM UTC+2 Axel Wagner wrote:

> If you want to argue that `net/http` should not set the response code to 
> 200 by default, I would be inclined to agree. I don't particularly like 
> that the API even *allows* you not to explicitly set a response code. But 
> it does. And while it does, the best test is one that matches the behavior 
> of the production environment as closely as possible, full stop.
>
> Another way to look at it: Why do you believe you have to test that your 
> handler sets the response code to 200? Why should the test fail, if it 
> doesn't do it - given that *the production code* will still end up with the 
> right response code? If the response sent to the user is the right one - 
> why would it matter whether it was your Handler that set it, or the 
> framework?
>
> On Sun, Oct 15, 2023 at 10:22 PM Simon Walter  wrote:
>
>> How does that explain why it is a good idea?
>>
>> Perhaps my concern is not clear enough.
>>
>> For example:
>>
>> n := 5
>> funcThatShouldSetNtoFive()
>> if n != 5 {
>>   panic("n is not 5)
>> }
>>
>> This is not a good test.
>>
>> I can check if the value has changed by:
>>
>> n := 0
>> funcThatShouldSetNtoFive()
>> if n != 5 {
>>   panic("n is not 5)
>> }
>>
>> That's a bit more sensible.
>>
>> Wouldn't it be less risky for a test to fail by default? Removal of the 
>> call to funcThatShouldSetNtoFive, IMO, should result in failure.
>>
>> On Sunday, October 15, 2023 at 6:10:36 PM UTC+2 Axel Wagner wrote:
>>
>>> A default `net/http` server also uses 200 as the default response code. 
>>> The behavior of an `http.Handler` not setting a response code should be the 
>>> same, if it uses `httptest`, as if it uses `net/http`.
>>>
>>> On Sun, Oct 15, 2023 at 5:17 PM Simon Walter  wrote:
>>>
 Hi all,

 What is the reason that ResponseRecorder HTTP status code defaults to 
 200?


 https://cs.opensource.google/go/go/+/refs/tags/go1.21.3:src/net/http/httptest/recorder.go;drc=ff14e844d26090e09aa335d836f737c09a7a0402;l=55


 https://cs.opensource.google/go/go/+/refs/tags/go1.21.3:src/net/http/httptest/recorder.go;drc=ff14e844d26090e09aa335d836f737c09a7a0402;l=196

 Can someone explain to me why this is a good idea? Would it not make 
 more sense to set it to a value that is not a valid HTTP response code 
 such 
 as 0?

 Simon

 -- 
 You received this message because you are subscribed to the Google 
 Groups "golang-nuts" group.
 To unsubscribe from this group and stop receiving emails from it, send 
 an email to golang-nuts...@googlegroups.com.
 To view this discussion on the web visit 
 https://groups.google.com/d/msgid/golang-nuts/321a84fa-3aeb-4f3a-ba4f-a05e797652d6n%40googlegroups.com
  
 
 .

>>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to golang-nuts...@googlegroups.com.
>>
> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/df053fb7-70bf-483d-afd6-4caee9937aa6n%40googlegroups.com
>>  
>> 
>> .
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/c69a5ab5-a6c7-4609-900d-38e31ddb74bbn%40googlegroups.com.

Re: [go-nuts] ResponseRecorder HTTP status code defaults to 200

['Axel Wagner' via golang-nuts]

If you want to argue that `net/http` should not set the response code to
200 by default, I would be inclined to agree. I don't particularly like
that the API even *allows* you not to explicitly set a response code. But
it does. And while it does, the best test is one that matches the behavior
of the production environment as closely as possible, full stop.

Another way to look at it: Why do you believe you have to test that your
handler sets the response code to 200? Why should the test fail, if it
doesn't do it - given that *the production code* will still end up with the
right response code? If the response sent to the user is the right one -
why would it matter whether it was your Handler that set it, or the
framework?

On Sun, Oct 15, 2023 at 10:22 PM Simon Walter  wrote:

> How does that explain why it is a good idea?
>
> Perhaps my concern is not clear enough.
>
> For example:
>
> n := 5
> funcThatShouldSetNtoFive()
> if n != 5 {
>   panic("n is not 5)
> }
>
> This is not a good test.
>
> I can check if the value has changed by:
>
> n := 0
> funcThatShouldSetNtoFive()
> if n != 5 {
>   panic("n is not 5)
> }
>
> That's a bit more sensible.
>
> Wouldn't it be less risky for a test to fail by default? Removal of the
> call to funcThatShouldSetNtoFive, IMO, should result in failure.
>
> On Sunday, October 15, 2023 at 6:10:36 PM UTC+2 Axel Wagner wrote:
>
>> A default `net/http` server also uses 200 as the default response code.
>> The behavior of an `http.Handler` not setting a response code should be the
>> same, if it uses `httptest`, as if it uses `net/http`.
>>
>> On Sun, Oct 15, 2023 at 5:17 PM Simon Walter  wrote:
>>
>>> Hi all,
>>>
>>> What is the reason that ResponseRecorder HTTP status code defaults to
>>> 200?
>>>
>>>
>>> https://cs.opensource.google/go/go/+/refs/tags/go1.21.3:src/net/http/httptest/recorder.go;drc=ff14e844d26090e09aa335d836f737c09a7a0402;l=55
>>>
>>>
>>> https://cs.opensource.google/go/go/+/refs/tags/go1.21.3:src/net/http/httptest/recorder.go;drc=ff14e844d26090e09aa335d836f737c09a7a0402;l=196
>>>
>>> Can someone explain to me why this is a good idea? Would it not make
>>> more sense to set it to a value that is not a valid HTTP response code such
>>> as 0?
>>>
>>> Simon
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "golang-nuts" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to golang-nuts...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/golang-nuts/321a84fa-3aeb-4f3a-ba4f-a05e797652d6n%40googlegroups.com
>>> 
>>> .
>>>
>> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/df053fb7-70bf-483d-afd6-4caee9937aa6n%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAEkBMfEq0Du--r2oGbxF73JujHr1aLz8kDAqic7B6Eo0FpEZDw%40mail.gmail.com.

Re: [go-nuts] ResponseRecorder HTTP status code defaults to 200

[Simon Walter]

How does that explain why it is a good idea?

Perhaps my concern is not clear enough.

For example:

n := 5
funcThatShouldSetNtoFive()
if n != 5 {
  panic("n is not 5)
}

This is not a good test.

I can check if the value has changed by:

n := 0
funcThatShouldSetNtoFive()
if n != 5 {
  panic("n is not 5)
}

That's a bit more sensible.

Wouldn't it be less risky for a test to fail by default? Removal of the 
call to funcThatShouldSetNtoFive, IMO, should result in failure.

On Sunday, October 15, 2023 at 6:10:36 PM UTC+2 Axel Wagner wrote:

> A default `net/http` server also uses 200 as the default response code. 
> The behavior of an `http.Handler` not setting a response code should be the 
> same, if it uses `httptest`, as if it uses `net/http`.
>
> On Sun, Oct 15, 2023 at 5:17 PM Simon Walter  wrote:
>
>> Hi all,
>>
>> What is the reason that ResponseRecorder HTTP status code defaults to 200?
>>
>>
>> https://cs.opensource.google/go/go/+/refs/tags/go1.21.3:src/net/http/httptest/recorder.go;drc=ff14e844d26090e09aa335d836f737c09a7a0402;l=55
>>
>>
>> https://cs.opensource.google/go/go/+/refs/tags/go1.21.3:src/net/http/httptest/recorder.go;drc=ff14e844d26090e09aa335d836f737c09a7a0402;l=196
>>
>> Can someone explain to me why this is a good idea? Would it not make more 
>> sense to set it to a value that is not a valid HTTP response code such as 0?
>>
>> Simon
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to golang-nuts...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/321a84fa-3aeb-4f3a-ba4f-a05e797652d6n%40googlegroups.com
>>  
>> 
>> .
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/df053fb7-70bf-483d-afd6-4caee9937aa6n%40googlegroups.com.

Re: [go-nuts] ResponseRecorder HTTP status code defaults to 200

['Axel Wagner' via golang-nuts]

A default `net/http` server also uses 200 as the default response code. The
behavior of an `http.Handler` not setting a response code should be the
same, if it uses `httptest`, as if it uses `net/http`.

On Sun, Oct 15, 2023 at 5:17 PM Simon Walter  wrote:

> Hi all,
>
> What is the reason that ResponseRecorder HTTP status code defaults to 200?
>
>
> https://cs.opensource.google/go/go/+/refs/tags/go1.21.3:src/net/http/httptest/recorder.go;drc=ff14e844d26090e09aa335d836f737c09a7a0402;l=55
>
>
> https://cs.opensource.google/go/go/+/refs/tags/go1.21.3:src/net/http/httptest/recorder.go;drc=ff14e844d26090e09aa335d836f737c09a7a0402;l=196
>
> Can someone explain to me why this is a good idea? Would it not make more
> sense to set it to a value that is not a valid HTTP response code such as 0?
>
> Simon
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/321a84fa-3aeb-4f3a-ba4f-a05e797652d6n%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAEkBMfG88A7dw2G8B_K%2B5TXjpS68Dxpg8opJu687wQgp%2B%3D68Zw%40mail.gmail.com.

[go-nuts] ResponseRecorder HTTP status code defaults to 200

[Simon Walter]

Hi all,

What is the reason that ResponseRecorder HTTP status code defaults to 200?

https://cs.opensource.google/go/go/+/refs/tags/go1.21.3:src/net/http/httptest/recorder.go;drc=ff14e844d26090e09aa335d836f737c09a7a0402;l=55

https://cs.opensource.google/go/go/+/refs/tags/go1.21.3:src/net/http/httptest/recorder.go;drc=ff14e844d26090e09aa335d836f737c09a7a0402;l=196

Can someone explain to me why this is a good idea? Would it not make more 
sense to set it to a value that is not a valid HTTP response code such as 0?

Simon

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/321a84fa-3aeb-4f3a-ba4f-a05e797652d6n%40googlegroups.com.