[pass] Wanted: Test Suite

[Lukas Fleischer]

On Sat, 19 Apr 2014 at 18:56:34, Von Welch wrote:
> Jason, all,
> 
> I've added a few more tests, enough to to find a few more issues. I'm going
> to pause at this point and wait for feedback to see if we agree this is the
> right path before doing more. The basic approach seems solid to me with a
> few small issues/questions to resolve:
> 
> 1) Unencrypted GPG key vs GPG-agent. Except for some weirdness with 'pass
> init' with an unencrypted gpg key and a closed stdin, an unencrypted key
> seems to work well. It seems simpler than getting a gpg-agent running.
> Acceptable or do we really want to use an agent for testing?
> 

I would say it is fine to use an unencrypted key -- at least for the
very basic tests.

> 2) "Building" pass. I figured out I really needed a version of the pass
> script to test with that has the platform-specific stuff replaced.
> Currently 'make install' is the only way to create a fully-functional pass
> script, but I don't want to require installation for testing. Hence in my
> branch I split the 'make install' process into 'make' which creates the
> platform-specific script and 'make install' which installs it. This lets
> you run 'make && make tests' without an install (actually 'make tests' will
> do a 'make' if needed, but you get the idea.) Sound reasonable?
> 

Sounds good to me. However, the current Makefile adds a reference to
"/usr/lib/password-store.platform.sh" (shouldn't that rather be
"/usr/lib/password-store/platform.sh"?) to the shell script. So simply
splitting the Makefile target won't work.

What I suggest is:

* Rename password-store.sh to password-store.sh.in.

* Use m4 (or some other tool) to inline the correct platform-specific
  code into password-store.sh.in and save the modified file as
  password-store.sh when running `make`.

* Just install(1) the files when running `make install`.

> 3) 'pass insert' requires interactivity. It insists on asking for the
> password twice even if stdin is not a terminal (a pipe). We'll either need
> to change that behavior, find some clever way of working around it for
> testing, or just decide it's not part of the test suite.
> 

What about `echo $secret | pass insert -e $pw`? Doesn't that work?

> 4) Going further with regards to interactivity, I have no idea how to test
> 'pass edit' at this point. I guess one could create a vimscript or
> something similar to simulate a user typing? Or just not worry about it for
> the test suite.
> 

How about just doing something like `EDITOR=magic.sh pass edit`, where
magic.sh is a shell script that uses sed(1) to modify the password?

> Von
> [...]