Utility functions for package testing that read the source code

[Robert Johnstone]

I recently found the package github.com/matryer/is, and really liked its trick of loading the source code (found using runtime.Callers) so that the the messages for test failures could be created automatically.  Enough that I experimented with my own package.  However, this does mean that the messages can not be created if the test binary is run on a separate machine, or in a sandbox.  I can't think of any cases where this would be an issue, but (as an example), it does break on the playground.

Does anyone have experience with this technique in production?

[roger peppe]

I've been using packages that use this technique for a long time now (first gopkg.in/check.v1, and latterly github.com/frankban/quicktest), and I can confirm that it works great. In general, tests can assume that they're being run in the package source directory because they're entitled to read file resources from there (for example from the testdata directory), so running a test binary on a separate machine isn't useful in general unless you pull across the other files too.

On Tue, 24 Sep 2019 at 14:52, Robert Johnstone <r.w.jo...@gmail.com> wrote:

I recently found the package github.com/matryer/is, and really liked its trick of loading the source code (found using runtime.Callers) so that the the messages for test failures could be created automatically.  Enough that I experimented with my own package.  However, this does mean that the messages can not be created if the test binary is run on a separate machine, or in a sandbox.  I can't think of any cases where this would be an issue, but (as an example), it does break on the playground.

Does anyone have experience with this technique in production?

--
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/d7a801c1-17aa-4f4b-9e46-abcc36fd49ff%40googlegroups.com.

[Robert Johnstone]

Thank-you for the feedback.  I will also checkout the packages that you mentioned.  No need to reinvent the wheel.

Robert

On Wednesday, 25 September 2019 08:15:19 UTC-4, rog wrote:

I've been using packages that use this technique for a long time now (first gopkg.in/check.v1, and latterly github.com/frankban/quicktest), and I can confirm that it works great. In general, tests can assume that they're being run in the package source directory because they're entitled to read file resources from there (for example from the testdata directory), so running a test binary on a separate machine isn't useful in general unless you pull across the other files too.

On Tue, 24 Sep 2019 at 14:52, Robert Johnstone <r.w.j...@gmail.com> wrote:

I recently found the package github.com/matryer/is, and really liked its trick of loading the source code (found using runtime.Callers) so that the the messages for test failures could be created automatically.  Enough that I experimented with my own package.  However, this does mean that the messages can not be created if the test binary is run on a separate machine, or in a sandbox.  I can't think of any cases where this would be an issue, but (as an example), it does break on the playground.

Does anyone have experience with this technique in production?

--
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 golan...@googlegroups.com.