summary: Can someone please show me how to properly write the tests I'm trying to write? Code snippets below should make it pretty clear what I'm trying to test. Thanks.
There aren't any docs on how to write new completion tests, only on how to run existing ones, but I found the existing tests, and library.exp, and have had some luck making new tests. Luckily, I already know what expect(1) is, having used it for something back in the days of modems, IIRC. What I could use some help with is the TCL layer that's driving expect, since I've never used TCL. Notes on what should be in a doc somewhere that I had to figure out: * run sync_after_int to send a ^c to get a new line after a test (turns out my command line ended up looking like apt-get apt-get purge base-files apt-get changelog base-files ... ) * assert_complete is just a wrapper for assert_complete_one, assert_complete_many, assert_no_complete. * assert_complete_partial is for?? I have no idea. All library.exp has to say for it is: "# Make sure a partial argument is completed." tried it in place of assert_complete, but still no luck. So in apt-get.exp, I was going to add tests for all the code-paths that generate package lists in different ways. # PASS: purge completes only on installed packages assert_complete_one {base-files} "apt-get purge base-fi" sync_after_int # This fails: source pkg ada-reference-manual builds ...-2005 and ...-2012. assert_complete {ada-reference-manual-2005 ada-reference-manual-2012} "apt-get download ada-ref" sync_after_int [dbg.log] <snip> expect: does "ada-reference-manual-2005 ada-reference-manual-2012\r\n/@apt-get download ada-reference-manual-20" (spawn_id exp9) match regular expression "^ada-reference-manual-2005\s+ada-reference-manual-2012\s+/@apt-get download ada-refada-reference-manual-20$"? Gate "ada-reference-manual-2005*ada-reference-manual-2012*/@apt-get download ada-refada-reference-manual-20"? gate=no expect: timed out FAIL: apt-get download ada-ref should show completions Note the command line expect is looking for after the completion: /@apt-get download ada-refada-reference-manual-20$ It's the partial I completed on with the longest common prefix appended in full. What bash actually printed was, correctly, /@apt-get download ada-reference-manual-20 So how do I assert_complete_SOMETHING to properly write this test, and the rest of the ones I wanted to write: # FAIL: looking for /@apt-get source ada-refada-reference-manual assert_complete {ada-reference-manual ada-reference-manual-2005 ada-reference-manual-2012} "apt-get source ada-ref" sync_after_int # FAIL: also tried assert_complete_partial: assert_complete_partial {ada-reference-manual-2005 ada-reference-manual-2012} "apt-get download" "ada-ref" sync_after_int # still looking for /@apt-get download ada-refada-reference-manual-20 # PASS: # boost-defaults builds libboost*, but no binary package has its name. # Ubuntu ships it in main, not universe, so it should be in everyone's pkg lists. assert_no_complete "apt-get changelog boost-def" sync_after_int # FAIL: slightly different results here assert_complete_one {boost-defaults} "apt-get source boost-def" sync_after_int expect: does "aults " (spawn_id exp9) match regular expression "^boost-defaults $"? Gate "boost-defaults "? gate=no "^/@$"? Gate "/@"? gate=no expect: timed out FAIL: apt-get source boost-def should show completion So it's expecting to see the whole thing, not just the completed chars that get appended to the command line. I forget why I even started poking at the apt-get completions. Probably one of the first ones I came to, looking for examples to base tests on for _longopt. There are a few ways _longopt currently behaves badly, and testcases to document exactly how I want it to behave would be the best documentation for my changes to the code, as well as being useful tests. Also, on the subject of tests for apt-get, I had a hard time choosing package names that won't make the test fail when Debian/Ubuntu change in the future. And since the apt-get completions apparently can check for installed packages on an RPM system, who knows what will be available / installed, if apt-get is there on a non-Debian-derived system. I went with base-files because it's a longish name with a unique prefix, and essential + required in Debianish systems, so it's safe to write a test that assumes it's installed. For an available source package that doesn't have a binary package of the same name, there's boost-defaults, in Ubuntu's main (not univers) section. And ada-reference-manual is interesting in that it builds two binary packages that include the source package name as a prefix. IDK if these tests are going to end up being brittle and break when the archive changes, or break on non-Debian systems. -- #define X(x,y) x##y Peter Cordes ; e-mail: X(peter@cor , des.ca) "The gods confound the man who first found out how to distinguish the hours! Confound him, too, who in this place set up a sundial, to cut and hack my day so wretchedly into small pieces!" -- Plautus, 200 BC
signature.asc
Description: Digital signature
_______________________________________________ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/bash-completion-devel