Re: [go-nuts] cgo: how to generate crash report/coredump on macOS for SIGSEGV

[aihui zhu]

thank you and yes, i'm trying to debug a SIGSEGV occurred in C code. 

i'm going changed my C code to some other way, since it's a bit difficult 
to retrieve the stack trace for debugging..
On Saturday, October 3, 2020 at 1:12:36 PM UTC+8 Kurtis Rader wrote:

> On Fri, Oct 2, 2020 at 9:49 PM aihui zhu  wrote:
>
>> .crash file is also acceptable for me, if it contains a stack trace.
>>
>
> No, it does not. At least not for me when running a trivial C program that 
> simply dereferences a NULL pointer. It does contain some information (e.g., 
> the contents of the CPU registers) that coule be useful in deducing the 
> state of the program but a macOS ".crash" file does not contain a stack 
> trace.
>
> The default Go behavior for reporting panics does output stack traces. 
> However, I have no idea what CGo does and would be surprised if a panic 
> from the "C" code resulted in a useful backtrace of that code written to 
> stdout/stderr. So the problem seems to be that you are melding Go and C 
> code on macOS, the C code is causing a fatal error (most likely a SIGSEGV), 
> and you're trying to find the bug in the C code. Yes?
>
> -- 
> Kurtis Rader
> Caretaker of the exceptional canines Junior and Hank
>

-- 
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/e5d4de0f-8e5e-409e-87db-4f56369fad57n%40googlegroups.com.

Re: [go-nuts] cgo: how to generate crash report/coredump on macOS for SIGSEGV

[Kurtis Rader]

On Fri, Oct 2, 2020 at 9:49 PM aihui zhu  wrote:

> .crash file is also acceptable for me, if it contains a stack trace.
>

No, it does not. At least not for me when running a trivial C program that
simply dereferences a NULL pointer. It does contain some information (e.g.,
the contents of the CPU registers) that coule be useful in deducing the
state of the program but a macOS ".crash" file does not contain a stack
trace.

The default Go behavior for reporting panics does output stack traces.
However, I have no idea what CGo does and would be surprised if a panic
from the "C" code resulted in a useful backtrace of that code written to
stdout/stderr. So the problem seems to be that you are melding Go and C
code on macOS, the C code is causing a fatal error (most likely a SIGSEGV),
and you're trying to find the bug in the C code. Yes?

-- 
Kurtis Rader
Caretaker of the exceptional canines Junior and Hank

-- 
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/CABx2%3DD8%3D2EBBW1P6-QHavsX7-KzZNvZBTj9QNns_oWQNu3t14A%40mail.gmail.com.

Re: [go-nuts] cgo: how to generate crash report/coredump on macOS for SIGSEGV

[aihui zhu]

.crash file is also acceptable for me, if it contains a stack trace.

On Saturday, October 3, 2020 at 12:41:58 PM UTC+8 ren...@ix.netcom.com 
wrote:

> A crash file is not a core dump. It does not contain a memory dump. 
>
> On Oct 2, 2020, at 11:36 PM, Kurtis Rader  wrote:
>
> 
>
> On Fri, Oct 2, 2020 at 9:23 PM aihui zhu  wrote:
>
>> I mean that is there any way to expose SIGSEGV to macOS system just like 
>> a pure C program, so that the system could generate .crash file 
>> automatically.
>> currently, seems that go itself catch the SIGSEGV signal, and prints go 
>> trace back, so it doesn't trigger system default behavior for SIGSEGV.
>>
>
> That is correct. And, no, there is no way for that to result in a core 
> dump unless you build a custom Go runtime that changes the behavior of the 
> "crash()" function in src/runtime/signal_unix.go. That is for the reason 
> explained in the doc string in that function: You would end up with a huge 
> core dump file that would probably take an hour or more to create. Do you 
> actually have enough disk space (> 128 GB free space) and are willing to 
> wait upwards of an hour for the core file to be created? If so then I, and 
> no doubt others, would be interested in hearing from you why letting Go 
> behave that way on macOS is sensible for 99% of people running Go programs 
> on macOS.
>
> -- 
> Kurtis Rader
> Caretaker of the exceptional canines Junior and Hank
>
> -- 
>
> 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/CABx2%3DD9-qWpfrHzo6SHspAfxbk7EymGmSbj2Wb4squ1iRur-hg%40mail.gmail.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/d50f6a1e-6d77-4f4e-bfce-df108005de42n%40googlegroups.com.

Re: [go-nuts] cgo: how to generate crash report/coredump on macOS for SIGSEGV

[Kurtis Rader]

On Fri, Oct 2, 2020 at 9:41 PM Robert Engels  wrote:

> A crash file is not a core dump. It does not contain a memory dump.
>

Yes. I addressed that in a different reply than the one you responded to.
So I'm a wee bit confused what to take away from your comment, Robert. :-)

-- 
Kurtis Rader
Caretaker of the exceptional canines Junior and Hank

-- 
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/CABx2%3DD8iQO5xNK_XMrufVbcCrObtPvQd0OnEJP8%3D33jQSvF-OQ%40mail.gmail.com.

Re: [go-nuts] cgo: how to generate crash report/coredump on macOS for SIGSEGV

[Robert Engels]

A crash file is not a core dump. It does not contain a memory dump. 

> On Oct 2, 2020, at 11:36 PM, Kurtis Rader  wrote:
> 
> 
>> On Fri, Oct 2, 2020 at 9:23 PM aihui zhu  wrote:
> 
>> I mean that is there any way to expose SIGSEGV to macOS system just like a 
>> pure C program, so that the system could generate .crash file automatically.
>> currently, seems that go itself catch the SIGSEGV signal, and prints go 
>> trace back, so it doesn't trigger system default behavior for SIGSEGV.
> 
> That is correct. And, no, there is no way for that to result in a core dump 
> unless you build a custom Go runtime that changes the behavior of the 
> "crash()" function in src/runtime/signal_unix.go. That is for the reason 
> explained in the doc string in that function: You would end up with a huge 
> core dump file that would probably take an hour or more to create. Do you 
> actually have enough disk space (> 128 GB free space) and are willing to wait 
> upwards of an hour for the core file to be created? If so then I, and no 
> doubt others, would be interested in hearing from you why letting Go behave 
> that way on macOS is sensible for 99% of people running Go programs on macOS.
> 
> -- 
> Kurtis Rader
> Caretaker of the exceptional canines Junior and Hank
> -- 
> 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/CABx2%3DD9-qWpfrHzo6SHspAfxbk7EymGmSbj2Wb4squ1iRur-hg%40mail.gmail.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/B69A2624-ED93-4302-9E9A-3C3BE139FD8C%40ix.netcom.com.

Re: [go-nuts] cgo: how to generate crash report/coredump on macOS for SIGSEGV

[Kurtis Rader]

On Fri, Oct 2, 2020 at 9:23 PM aihui zhu  wrote:

> I mean that is there any way to expose SIGSEGV to macOS system just like a
> pure C program, so that the system could generate .crash file automatically.
> currently, seems that go itself catch the SIGSEGV signal, and prints go
> trace back, so it doesn't trigger system default behavior for SIGSEGV.
>

That is correct. And, no, there is no way for that to result in a core dump
unless you build a custom Go runtime that changes the behavior of the
"crash()" function in src/runtime/signal_unix.go. That is for the reason
explained in the doc string in that function: You would end up with a huge
core dump file that would probably take an hour or more to create. Do you
actually have enough disk space (> 128 GB free space) and are willing to
wait upwards of an hour for the core file to be created? If so then I, and
no doubt others, would be interested in hearing from you why letting Go
behave that way on macOS is sensible for 99% of people running Go programs
on macOS.

-- 
Kurtis Rader
Caretaker of the exceptional canines Junior and Hank

-- 
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/CABx2%3DD9-qWpfrHzo6SHspAfxbk7EymGmSbj2Wb4squ1iRur-hg%40mail.gmail.com.

Re: [go-nuts] cgo: how to generate crash report/coredump on macOS for SIGSEGV

[aihui zhu]

I mean that is there any way to expose SIGSEGV to macOS system just like a 
pure C program, so that the system could generate .crash file automatically.
currently, seems that go itself catch the SIGSEGV signal, and prints go 
trace back, so it doesn't trigger system default behavior for SIGSEGV.

please correct me if i'm wrong at something,  thank you.

On Saturday, October 3, 2020 at 10:53:51 AM UTC+8 Kurtis Rader wrote:

> On Fri, Oct 2, 2020 at 12:26 PM Ian Lance Taylor  wrote:
>
>> On Thu, Oct 1, 2020 at 10:44 PM aihui zhu  wrote:
>> >
>> > C program could generate a core dump file, my os is Big Sur beta.
>>
>> Thanks.
>>
>> I see now that for darwin-amd64 we do not generate core dumps.  Sorry
>> for forgetting about that.
>>
>> We have this comment:
>>
>> // OS X core dumps are linear dumps of the mapped memory,
>> // from the first virtual byte to the last, with zeros in the gaps.
>> // Because of the way we arrange the address space on 64-bit systems,
>> // this means the OS X core file will be >128 GB and even on a zippy
>> // workstation can take OS X well over an hour to write (uninterruptible).
>> // Save users from making that mistake.
>>
>> It may be worth investigating whether this is still a problem on
>> current macOS systems.  The comment in question is in
>> runtime/signal_unix.go.
>
>
> It  looks like this is still a problem on macOS (at least as of 10.15 
> Catalina). A trivial C program that does nothing more than
>
> char *p = 0;
> *p = 'x';
>
> results in a 2.1 GB core dump.
>
> It might be worth documenting this limitation in the 
> https://golang.org/pkg/runtime/ documentation. :-)
>
> -- 
> Kurtis Rader
> Caretaker of the exceptional canines Junior and Hank
>

-- 
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/abb89f94-173d-49cf-a70b-5a76c0f1334bn%40googlegroups.com.

Re: [go-nuts] cgo: how to generate crash report/coredump on macOS for SIGSEGV

[Kurtis Rader]

On Fri, Oct 2, 2020 at 12:26 PM Ian Lance Taylor  wrote:

> On Thu, Oct 1, 2020 at 10:44 PM aihui zhu  wrote:
> >
> > C program could generate a core dump file, my os is Big Sur beta.
>
> Thanks.
>
> I see now that for darwin-amd64 we do not generate core dumps.  Sorry
> for forgetting about that.
>
> We have this comment:
>
> // OS X core dumps are linear dumps of the mapped memory,
> // from the first virtual byte to the last, with zeros in the gaps.
> // Because of the way we arrange the address space on 64-bit systems,
> // this means the OS X core file will be >128 GB and even on a zippy
> // workstation can take OS X well over an hour to write (uninterruptible).
> // Save users from making that mistake.
>
> It may be worth investigating whether this is still a problem on
> current macOS systems.  The comment in question is in
> runtime/signal_unix.go.


It  looks like this is still a problem on macOS (at least as of 10.15
Catalina). A trivial C program that does nothing more than

char *p = 0;
*p = 'x';

results in a 2.1 GB core dump.

It might be worth documenting this limitation in the
https://golang.org/pkg/runtime/ documentation. :-)

-- 
Kurtis Rader
Caretaker of the exceptional canines Junior and Hank

-- 
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/CABx2%3DD9A4RRUQRdL4td%2By9%3DjwSXKZwJrhpajcrS%3Dqs5wLDwnSg%40mail.gmail.com.

Re: [go-nuts] cgo: how to generate crash report/coredump on macOS for SIGSEGV

[Kurtis Rader]

On Fri, Oct 2, 2020 at 5:29 PM aihui zhu  wrote:

> thank you.  i see that there are also .crash file generated at
> ~/Library/Logs/DiagnosticReports
> ```
> ➜  ~ ls Library/Logs/DiagnosticReports/a.out_2020-10-02-1337* -lh
> -rw--- 1 zah _analyticsusers 22K Oct  2 13:37
> Library/Logs/DiagnosticReports/a.out_2020-10-02-133721_hac.crash
> -rw--- 1 zah _analyticsusers 21K Oct  2 13:37
> Library/Logs/DiagnosticReports/a.out_2020-10-02-133751_hac.crash
> ```
> could go generates .crash file?
>

Those are simple text files that contain a report of the event that
resulted in an application crash. They are created by macOS. The program
that crashes does not create that file. Which means that Go should not
attempt to create that file. Also, Go already emits most of what you need
to know when a Go program crashes.

-- 
Kurtis Rader
Caretaker of the exceptional canines Junior and Hank

-- 
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/CABx2%3DD9fmh9S%3D9eRkiSzHY%2BcBtBLqAo4YPP5EyuHLv7nqwB8%2Bw%40mail.gmail.com.

Re: [go-nuts] cgo: how to generate crash report/coredump on macOS for SIGSEGV

[aihui zhu]

thank you.  i see that there are also .crash file generated at 
~/Library/Logs/DiagnosticReports
```
➜  ~ ls Library/Logs/DiagnosticReports/a.out_2020-10-02-1337* -lh
-rw--- 1 zah _analyticsusers 22K Oct  2 13:37 
Library/Logs/DiagnosticReports/a.out_2020-10-02-133721_hac.crash
-rw--- 1 zah _analyticsusers 21K Oct  2 13:37 
Library/Logs/DiagnosticReports/a.out_2020-10-02-133751_hac.crash
```
could go generates .crash file?
On Saturday, October 3, 2020 at 3:26:13 AM UTC+8 Ian Lance Taylor wrote:

> On Thu, Oct 1, 2020 at 10:44 PM aihui zhu  wrote:
> >
> > C program could generate a core dump file, my os is Big Sur beta.
>
> Thanks.
>
> I see now that for darwin-amd64 we do not generate core dumps. Sorry
> for forgetting about that.
>
> We have this comment:
>
> // OS X core dumps are linear dumps of the mapped memory,
> // from the first virtual byte to the last, with zeros in the gaps.
> // Because of the way we arrange the address space on 64-bit systems,
> // this means the OS X core file will be >128 GB and even on a zippy
> // workstation can take OS X well over an hour to write (uninterruptible).
> // Save users from making that mistake.
>
> It may be worth investigating whether this is still a problem on
> current macOS systems. The comment in question is in
> runtime/signal_unix.go.
>
> Ian
>

-- 
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/b6a77509-a810-4d1f-bf50-6dc3e1fc94d0n%40googlegroups.com.

Re: [go-nuts] cgo: how to generate crash report/coredump on macOS for SIGSEGV

[Ian Lance Taylor]

On Thu, Oct 1, 2020 at 10:44 PM aihui zhu  wrote:
>
> C program could generate a core dump file, my os is Big Sur beta.

Thanks.

I see now that for darwin-amd64 we do not generate core dumps.  Sorry
for forgetting about that.

We have this comment:

// OS X core dumps are linear dumps of the mapped memory,
// from the first virtual byte to the last, with zeros in the gaps.
// Because of the way we arrange the address space on 64-bit systems,
// this means the OS X core file will be >128 GB and even on a zippy
// workstation can take OS X well over an hour to write (uninterruptible).
// Save users from making that mistake.

It may be worth investigating whether this is still a problem on
current macOS systems.  The comment in question is in
runtime/signal_unix.go.

Ian

-- 
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/CAOyqgcUY%3D5x3AS9_bwETojn%2B7uXxvPxu3FJT4naLkH1zL689dQ%40mail.gmail.com.

Re: [go-nuts] comment conversion script? inlncmt.awk?

[quin...@gmail.com]

inlncmt.awk was my joke-ey guess at what such a thing might be called,
but gofmtcomment 
 sounds just 
like what I want.

Many thanks,

-Steve

On Friday, 2 October 2020 at 12:02:11 UTC+1 Shulhan wrote:

>
>
> > On 2 Oct 2020, at 15.05, quin...@gmail.com  wrote:
> > 
> > Hi,
> > 
> > When I was writing C I used to use a script bcmt.awk (it might have been 
> one of russ's or erikQ's, I cannot remember) to convert c++ style comments 
> to K syle. Now I am a proud go programmer I find my fingers still want to 
> put starts before and after my slashes when writing comments.
> > 
> > Has anyone written inlncmt.awk or similar to help me fix my poor style? 
> Though this may sound simple it needs care to deal with /* and */ in 
> strings and multiline comments nicely. This is why I ask.
> > 
>
> I am not familiar with inlncmt.awk, did you mean a tools to convert from 
> "/**/" to "//" ?
> If yes, I have gofmtcomment [1].
>
> [1] https://pkg.go.dev/github.com/shuLhan/share/cmd/gofmtcomment
>
>

-- 
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/c4b7173d-467e-4638-ab10-8dc0230c3f35n%40googlegroups.com.

[go-nuts] Re: Proper way of mocking interfaces in unit tests - the golang way

[Jason Phillips]

In the general case, all testify assertions are doing under the hood is 
call t.Errorf (see here 
).
 
If you're calling the "FailNow" set of functions that's followed by 
t.FailNow, which ends the test early. As others have stated, that's no 
different than you calling those methods on testing.T, directly.

What led you to believe that using testify/assert is against Go best 
practices?

On Friday, October 2, 2020 at 7:27:28 AM UTC-4 vlad...@varank.in wrote:

> Hey,
>
> I don't think the statement about "assert going against the best practices 
> in go unit tests" stands against the reality, sorry. One definitely doesn't 
> have to use a separate assertion package to write unit-tests in Go, 
> comparing to some other programming languages. But there is really no much 
> difference between using an assertion of t.Fail-ing manually.
>
> In our project, we use testify assertions (only for statistics: our 
> monorepo is ~400K lines of Go code with every package covered with 
> unit-tests) and it works great just by reducing the total number of lines 
> in our test files and making them much more manageable (we have unit-tests 
> files that over years has grown over 3K+ LOC now).
>
> Depending on the interface, we usually create a separate "controlled" 
> implementation, that we use in unit-tests. E.g. if we implemented a 
> DataStore, we would have an in-memory implementation with additional 
> Setter-methods, that accepted an optional "hook", that allowed us to return 
> an error.
>
> We don't use "testify/mock" because we aren't interested in verifying the 
> calls or the arguments that were passed to the mock. Usually, it's easier 
> to write a fake implementation. I.e. our testing implementations are more 
> "fakes" than "mocks".
>
> One neat thing about that approach is that testing implementation doesn't 
> always have to expose lots of knobs. If one unit-test needs to tune the 
> behaviour, you can always stub the dependency right in-place and use it for 
> this single test only. E.g.
>
> type testDataStore struct {
> callFooFunc() error
> }
>
> func (s *testDataStore) Foo() error {
> return s.callFooFunc()
> }
>
> func TestSomething(t *testing.T) {
> ds :=  {
> callFooFunc: func() error {
>return fmt.Errorf("a very specific error that make sence to 
> test against in this test only")
> }
> }
> // ···
> }
>
> Hope that makes sense.
>
> On Thursday, October 1, 2020 at 6:26:19 PM UTC+2 krish...@gmail.com wrote:
>
>> We are working on a full scale production app with go backend.
>>
>> For unit tests, we need to mock the dependent interfaces either by 
>> creating our own mock implementation of the interface or by using third 
>> party packages like *testify/mocks.*
>>
>> If we use testify, there will be a tendency for the developers to use 
>> *assert 
>> *statements which is against the best practices in go unit tests. (We 
>> use t.Fail instead of asserts)
>>
>> If we create manual mocks, we will end up creating two implementations 
>> for each interface, one for the program and another for the unit testing. 
>> Also we cannot test by mocking with different outputs from the 
>> dependencies. example if the dependency return an error.
>>
>> Please suggest which the right approach here.
>>
>

-- 
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/9d20e10b-e6a7-45d1-ad62-b7883a844b6fn%40googlegroups.com.

[go-nuts] Re: Proper way of mocking interfaces in unit tests - the golang way

[Vladimir Varankin]

Hey,

I don't think the statement about "assert going against the best practices 
in go unit tests" stands against the reality, sorry. One definitely doesn't 
have to use a separate assertion package to write unit-tests in Go, 
comparing to some other programming languages. But there is really no much 
difference between using an assertion of t.Fail-ing manually.

In our project, we use testify assertions (only for statistics: our 
monorepo is ~400K lines of Go code with every package covered with 
unit-tests) and it works great just by reducing the total number of lines 
in our test files and making them much more manageable (we have unit-tests 
files that over years has grown over 3K+ LOC now).

Depending on the interface, we usually create a separate "controlled" 
implementation, that we use in unit-tests. E.g. if we implemented a 
DataStore, we would have an in-memory implementation with additional 
Setter-methods, that accepted an optional "hook", that allowed us to return 
an error.

We don't use "testify/mock" because we aren't interested in verifying the 
calls or the arguments that were passed to the mock. Usually, it's easier 
to write a fake implementation. I.e. our testing implementations are more 
"fakes" than "mocks".

One neat thing about that approach is that testing implementation doesn't 
always have to expose lots of knobs. If one unit-test needs to tune the 
behaviour, you can always stub the dependency right in-place and use it for 
this single test only. E.g.

type testDataStore struct {
callFooFunc() error
}

func (s *testDataStore) Foo() error {
return s.callFooFunc()
}

func TestSomething(t *testing.T) {
ds :=  {
callFooFunc: func() error {
   return fmt.Errorf("a very specific error that make sence to test 
against in this test only")
}
}
// ···
}

Hope that makes sense.

On Thursday, October 1, 2020 at 6:26:19 PM UTC+2 krish...@gmail.com wrote:

> We are working on a full scale production app with go backend.
>
> For unit tests, we need to mock the dependent interfaces either by 
> creating our own mock implementation of the interface or by using third 
> party packages like *testify/mocks.*
>
> If we use testify, there will be a tendency for the developers to use *assert 
> *statements which is against the best practices in go unit tests. (We use 
> t.Fail instead of asserts)
>
> If we create manual mocks, we will end up creating two implementations for 
> each interface, one for the program and another for the unit testing. Also 
> we cannot test by mocking with different outputs from the dependencies. 
> example if the dependency return an error.
>
> Please suggest which the right approach here.
>

-- 
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/6102c3f1-d398-4e0b-9cc8-fc4a848f4c7bn%40googlegroups.com.

Re: [go-nuts] comment conversion script? inlncmt.awk?

[Shulhan]

> On 2 Oct 2020, at 15.05, quin...@gmail.com  wrote:
> 
> Hi,
> 
> When I was writing C I used to use a script bcmt.awk (it might have been one 
> of russ's or erikQ's, I cannot remember) to convert c++ style comments to K 
> syle. Now I am a proud go programmer I find my fingers still want to put 
> starts before and after my slashes when writing comments.
> 
> Has anyone written inlncmt.awk or similar to help me fix my poor style? 
> Though this may sound simple it needs care to deal with /* and */ in strings 
> and multiline comments nicely. This is why I ask.
> 

I am not familiar with inlncmt.awk, did you mean a tools to convert from "/**/" 
to "//" ?
If yes, I have gofmtcomment [1].

[1] https://pkg.go.dev/github.com/shuLhan/share/cmd/gofmtcomment

-- 
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/E924BC0F-D88F-45C7-A6C2-C689E0123FCA%40gmail.com.

[go-nuts] comment conversion script? inlncmt.awk?

[quin...@gmail.com]

Hi,

When I was writing C I used to use a script bcmt.awk (it might have been 
one of russ's or erikQ's, I cannot remember) to convert c++ style comments 
to K syle. Now I am a proud go programmer I find my fingers still want to 
put starts before and after my slashes when writing comments.

Has anyone written inlncmt.awk or similar to help me fix my poor style? 
Though this may sound simple it needs care to deal with /* and */ in 
strings and multiline comments nicely. This is why I ask.

Thanks,

-Steve

-- 
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/3564eccc-9a62-4f5f-8982-c762e3668070n%40googlegroups.com.