Is there a way to specify or use the tmp directory used in testing?

[Leam Hall]

My program uses data and template files located relative to the binary. Since go test creates the binary under test in /tmp/go-build....., there are no data or template files. How do I either specify what directory to build in so I can create the files, or get the tmp directory name before the tests are run so I can write files to it?

Thanks!

Leam

--
Site Automation Engineer (reuel.net/resume)
Scribe: The Domici War (domiciwar.net)
General Ne'er-do-well (github.com/LeamHall)

[Levieux Michel]

Use absolute paths? Feels like you're trying to bend something very hard 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...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/7d8cf3dc-14ab-315f-ce5a-9e3cca877e17%40gmail.com.

[Amnon]

Use t.TestDir()
https://pkg.go.dev/testing#T.TempDir

[David Finkel]

On Wed, Feb 23, 2022 at 8:53 AM Leam Hall <leam...@gmail.com> wrote:

My program uses data and template files located relative to the binary. Since go test creates the binary under test in /tmp/go-build....., there are no data or template files. How do I either specify what directory to build in so I can create the files, or get the tmp directory name before the tests are run so I can write files to it?

When go test runs tests, they run with the current working directory inside the package's directory, so relative paths should work.

Another option that you might want to consider is using //go:embed directives to embed those files in your binary. (package doc: https://pkg.go.dev/embed)

This way you never need to resolve anything relative to the binary again.

Note: unless you use mlock(2) embedding in the binary shouldn't bloat memory usage, since the data will only be paged into memory at first-access.

Thanks!

Leam

--
Site Automation Engineer   (reuel.net/resume)
Scribe: The Domici War     (domiciwar.net)
General Ne'er-do-well      (github.com/LeamHall)

[Gergely Brautigam]

Hi!

The best way to do it is, to have these files in a folder next to the test called `testdata` and then when the test starts, simply copy them into a temp location. And then make your program work with an environment property or setting which can configure the path in which is loads these files from and set that environment property for the test to the Temp folder you just copied your files to.

And don't forget to defer os.RemoveAll(tmp) :)

[David Finkel]

On Wed, Feb 23, 2022 at 1:47 PM Gergely Brautigam <skarl...@gmail.com> wrote:

Hi!

The best way to do it is, to have these files in a folder next to the test called `testdata` and then when the test starts, simply copy them into a temp location. And then make your program work with an environment property or setting which can configure the path in which is loads these files from and set that environment property for the test to the Temp folder you just copied your files to.

And don't forget to defer os.RemoveAll(tmp) :)

You don't need this if you use t.TempDir to create the tempdir. :) 

On Wednesday, 23 February 2022 at 16:30:06 UTC+1 david....@gmail.com wrote:

On Wed, Feb 23, 2022 at 8:53 AM Leam Hall <leam...@gmail.com> wrote:

My program uses data and template files located relative to the binary. Since go test creates the binary under test in /tmp/go-build....., there are no data or template files. How do I either specify what directory to build in so I can create the files, or get the tmp directory name before the tests are run so I can write files to it?

When go test runs tests, they run with the current working directory inside the package's directory, so relative paths should work.

Another option that you might want to consider is using //go:embed directives to embed those files in your binary. (package doc: https://pkg.go.dev/embed)

This way you never need to resolve anything relative to the binary again.

Note: unless you use mlock(2) embedding in the binary shouldn't bloat memory usage, since the data will only be paged into memory at first-access.

Thanks!

Leam

--
Site Automation Engineer   (reuel.net/resume)
Scribe: The Domici War     (domiciwar.net)
General Ne'er-do-well      (github.com/LeamHall)

--
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/7d8cf3dc-14ab-315f-ce5a-9e3cca877e17%40gmail.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/8ffeae9e-ce1d-4a7d-af01-b24a1d13c7cdn%40googlegroups.com.

[Gergely Brautigam]

On Wednesday, 23 February 2022 at 19:58:04 UTC+1 david....@gmail.com wrote:

On Wed, Feb 23, 2022 at 1:47 PM Gergely Brautigam <skarl...@gmail.com> wrote:

Hi!

The best way to do it is, to have these files in a folder next to the test called `testdata` and then when the test starts, simply copy them into a temp location. And then make your program work with an environment property or setting which can configure the path in which is loads these files from and set that environment property for the test to the Temp folder you just copied your files to.

And don't forget to defer os.RemoveAll(tmp) :)

You don't need this if you use t.TempDir to create the tempdir. :) 

Oh, neat!

[Leam Hall]

My apologies for taking so long to respond; a new job and cold weather have taken up most of my time.

I have two versions of the application; one CLI and one web. The programs create characters for games and fiction, and use data text files relative to the binary ( <binary>/data/* ) to get names. The reason for not embedding names into the binary is so the data files can be altered to suit the user's needs. They may want Elven names, or Chinese, or whatever. The web program also uses template files, but those could probably be embedded.

The tests for the CLI work (https://github.com/makhidkarun/crewgen/blob/master/cmd/teamgen/main_test.go), but I have not figured out how to make the web version tests work (https://github.com/makhidkarun/crewgen/blob/master/cmd/crewgen/main_test.go). If I uncomment lines 38-57 of the web tests and run "go test" in that directory, I get:

###
Building crewgen...
Running crewgen tests...
Running in /tmp/TestHandleDocroot84710494/001, with /home/leam/lang/git/makhidkarun/crewgen/cmd/crewgen as dir.
open /tmp/go-build3480032656/b001/data/human_male_first.txt: no such file or directory
open /tmp/go-build3480032656/b001/data/human_last.txt: no such file or directory
open /tmp/go-build3480032656/b001/data/human_female_first.txt: no such file or directory
open /tmp/go-build3480032656/b001/data/human_last.txt: no such file or directory
2022/02/25 04:48:27 open /tmp/go-build3480032656/b001/web/layout.tmpl: no such file or directory
--- FAIL: TestHandleDocroot (0.00s)
--- FAIL: TestHandleDocroot/BaseCrewgenRun (0.00s)
main_test.go:53: Response code is 500
###

It seems that identifying the /tmp/go-build* directory would be useful, in that I could write testdata files there and do better tests. Otherwise, building in a specified pre-existing location so I can make sure the data files are already in place.

Thoughts?

Leam



On 2/23/22 09:26, David Finkel wrote:

>
>
> On Wed, Feb 23, 2022 at 8:53 AM Leam Hall <leam...@gmail.com <mailto:leam...@gmail.com>> wrote:
>
> My program uses data and template files located relative to the binary. Since go test creates the binary under test in /tmp/go-build....., there are no data or template files. How do I either specify what directory to build in so I can create the files, or get the tmp directory name before the tests are run so I can write files to it?
>
>
> When go test runs tests, they run with the current working directory inside the package's directory, so relative paths should work.
>

> Another option that you might want to consider is using //go:embed directives to embed those files in your binary. (package doc: https://pkg.go.dev/embed <https://pkg.go.dev/embed>)

> This way you never need to resolve anything relative to the binary again.
>
> Note: unless you use mlock(2) embedding in the binary shouldn't bloat memory usage, since the data will only be paged into memory at first-access.
>
>
> Thanks!
>
> Leam
>
> --

> Site Automation Engineer   (reuel.net/resume <http://reuel.net/resume>)
> Scribe: The Domici War     (domiciwar.net <http://domiciwar.net>)
> General Ne'er-do-well      (github.com/LeamHall <http://github.com/LeamHall>)

>
> --
> 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 <mailto:golang-nuts%2Bunsu...@googlegroups.com>.
> To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/7d8cf3dc-14ab-315f-ce5a-9e3cca877e17%40gmail.com <https://groups.google.com/d/msgid/golang-nuts/7d8cf3dc-14ab-315f-ce5a-9e3cca877e17%40gmail.com>.

[Sean Liao]

I would question the choice to place data relative to the binary vs relative to the working directory, or configurable via flags.

In a traditional (ie most) linux distro model, binaries are in (/usr)/bin/<binary> while the supporting data in in /usr/lib/<name> or /var/lib/<name>, maintaining the separation between the two, with the latter usually being configurable or having multiple layer of fallback.

Additionally, it is uncommon to have the binary directory be writable by a normal user.

Should you insist on using a path relative to the binary, os.Executable() will get you the absolute path of the (test) binary (standard caveats apply, read the docs).