Re: TAP testing for psql's tab completion code - Mailing list pgsql-hackers
From | Fabien COELHO |
---|---|
Subject | Re: TAP testing for psql's tab completion code |
Date | |
Msg-id | alpine.DEB.2.21.1912282212060.24861@pseudo Whole thread Raw |
In response to | TAP testing for psql's tab completion code (Tom Lane <tgl@sss.pgh.pa.us>) |
Responses |
Re: TAP testing for psql's tab completion code
|
List | pgsql-hackers |
Hello Tom, > We've often talked about the problem that we have no regression test > coverage for psql's tab completion code. I got interested in this > issue while messing with the filename completion logic therein [1], > so here is a draft patch that adds some testing for that code. > > This is just preliminary investigation, so I've made no attempt > to test tab-complete.c comprehensively (and I'm not sure there > would be much point in covering every last code path in it anyway). > Still, it does get us from zero to 43% coverage of that file > already, and it does good things for the coverage of input.c > and prompt.c as well. > > What I think is actually interesting at this stage is portability > of the tests. There are a number of issues: > > * The script requires Perl's IO::Pty module (indirectly, in that IPC::Run > requires that to make pty connections), which isn't installed everywhere. > I just made the script skip if that's not available, so that we're not > moving the goalposts for what has to be installed to run the TAP tests. > Is that the right answer? > > * It seems pretty likely that this won't work on Windows, given all the > caveats in the IPC::Run documentation about nonfunctionality of the pty > support there. Maybe we don't care, seeing that we don't really support > readline on Windows anyway. For the moment I assumed that the skip > conditions for --without-readline and/or missing-IO::Pty would cover > this, but we might need an explicit check for Windows too. Or maybe > somebody wants to try to make it work on Windows; but that won't be me. > > * What's even more likely to be problematic is small variations in the > output behavior of different readline and libedit versions. According > to my tests so far, though, all modern versions of them do pass these > test cases. I noted failures on very old Apple versions of libedit: > > 1. macOS 10.5's version of libedit seems not to honor > rl_completion_append_character; it never emits the trailing space > we're expecting. This seems like a plain old libedit bug, especially > since 10.4's version works as expected. > > 2. Both 10.4 and 10.5 emit the alternative table names in the wrong > order, suggesting that they're not internally sorting the completion > results. If this proves to be more widespread, we could likely fix > it by adding ORDER BY to the completion queries, but I'm not sure that > it's worth doing if only these dead macOS versions have the issue. > (On the other hand, it seems like bad practice to be issuing queries > that have LIMIT without ORDER BY, so maybe we should fix them anyway.) > > > I'm strongly tempted to just push this and see what the buildfarm > thinks of it. If it fails in lots of places, maybe the idea is a > dead end. If it works, I'd look into extending the tests --- in > particular, I'd like to have some coverage for the filename > completion logic. > > Thoughts? After you raised the issue, I submitted something last August, which did not attract much attention. https://commitfest.postgresql.org/26/2262/ It covers some tab-completion stuff. It uses Expect for the interactive stuff (tab completion, \h, ...). -- Fabien.
pgsql-hackers by date: