On Thu, Feb 9, 2023 at 4:33 PM Andres Freund <and...@anarazel.de> wrote: > The individual test is actually named tmp_install. I thought it might be > useful to add further things to the setup "stage", hence the more general > name.
I did notice that, but only after sitting with my initial confusion for a while. > I e.g. have a not-quite-done patch that creates a "template initdb", which > pg_regress and tap tests automatically use (except if non-default options are > required), which quite noticably reduces test times (*). But something needs > to > create the template initdb, and initdb doesn't run without an installation, so > we need to run it after the temp_install. > > Of course we could wrap that into one "test", but it seemed nicer to see if > you fail during installation, or during initdb. So for that I added a separate > test, that is also part of the setup suite. But what are the chances that the setup / tmp_install "test" will actually fail? It's almost a test in name only. > Of course we could still name the suite tmp_install (or to be consistent with > the confusing make naming, have a temp-install target, which creates the > tmp_install directory :)). I guess that'd still be less confusing? Yes, that definitely seems like an improvement. I don't care about the tiny inconsistency that this creates. I wonder if this could be addressed by adding another custom test setup, like --setup running, used whenever you want to just run one or two tests against an ad-hoc temporary installation? Offhand it seems as if add_test_setup() could support that requirement? -- Peter Geoghegan