Recent commits to derivepassphrase.git (791a882431f75bd28fc11b9fada74aa7c3fbe621)

Implement the TODO tests for the `vault` command-line interface

2025-08-15T06:51:10+02:00

Implement alluded to, but missing, tests for `derivepassphrase vault`:
passphrase usage based on stored configuration, passphrase usage based
on the command-line, and exporting configurations that were originally
smudged upon import.
</pre>

Replace the `vault` repetition tests with a faster version

2025-08-14T22:58:08+02:00

For asserting the correctness of `vault`'s repetition limitation
setting, we used to extract all size `r` substrings of the derived
passphrase (where `r` is the repetition count that is *not* allowed
anymore) and tested whether they contained more than one different
character (by building a set over the characters).  That works, but it
repeatedly builds sets, and scales badly with increased repetition
count.

Instead, we adopt the faster approach that examines the derived
passphrase once, character by character, keeping track of the longest
seen run of identical characters, and asserting that that run is within
the permitted repetition limit.  Although it consists of more
instructions, these are "simpler" instructions that do not involve set
object construction, and in particular, they are independent of the
repetition limit, leading to better scalability.  Sample runs with
Python's `timeit` module also indicate that for length-200 strings and
repetition limit 100, the set-building version takes 2-5 times as long
as the direct run counting version.  Given the nature of this code – it
runs in `hypothesis`, so is executed repeatedly and cannot afford to be
*too* slow –, I posit that the speed gain is worth the slightly indirect
measurement style.
</pre>

Remove hypothesis tests for config dependence of derived passphrases in `vault`

2025-08-14T22:47:35+02:00

Sadly, there exist configurations and pairs of master passphrases (and
presumably, pairs of services names as well) that lead to the same
derived passphrase.  (These are typically short-length derived
passphrases with strongly restricted character sets.)  Once `hypothesis`
has found such a set of inputs, its example database will cause it to
keep rediscovering that example.

Ideally, we want to express that given enough entropy through the
configuration, the chance of deriving the same passphrases with two
different master passphrases or two different service names becomes very
small.  However, this is a statement about the function's state space,
and I do not know how to sensibly express this statement in a unit-test
or `hypothesis`-test-compatible way, short of perhaps enumerating the
whole state space (which is computationally infeasible).  So, we remove
these tests of config dependence; they are clearly non-functional and
misleading.
</pre>

Rearrange tests as per the new groupings

2025-08-14T20:58:10+02:00

Also resolve some TODOs, usually by removing duplicate or
quasi-duplicate tests.
</pre>

Also regroup the vault tests into smaller groups

2025-08-14T19:10:17+02:00

As in a2c0a0b3b6f000d824787dabc011041549bda206, introduce further
classes/groupings for the `vault` derivation scheme tests, trimming test
names appropriately.
</pre>

Regroup the CLI and SSH agent tests into smaller groups

2025-08-11T21:50:42+02:00

Beyond the five main groups that reflect the original five test classes
for the command-line interface, introduce further classes/groupings for
related tests, and trim the test names appropriately.  In particular,
remove the ordinal in the test name until the new order (due to the new
class names and trimmed test names) sufficiently settles.  Do the same
for the SSH agent tests.  (This could have been done for all tests, but
with diminishing returns.)

The grouping currently (mostly) reflects thematic similarity, but in the
long run, we intend for it to reflect both thematic similarity and
common test environments, with respect to setup and teardown: tests of
the same group should look similar to each other too, and common code
among tests of the same group should be factored out if possible.

The grouping is inserted, syntactically, between the existing test
functions.  In particular, to keep the diff readable, we do not relocate
or reorder any test functions yet in this commit.  We add some TODOs to
indicate where further reordering or rewriting is necessary, beyond just
introducing new groups.

The intended (but not yet implemented) sharing of test setup and
teardown code will probably entail using fixtures, pytest's preferred
mechanism for shared setup and teardown.  However, as of this writing,
it is still an open question how to deal with `hypothesis`-based tests
in this scenario: they do not work well together with per-function test
fixtures, but we also do *not* want to have to (re-)implement all
setup/teardown pairs once as a fixture and once as a context manager.
</pre>

Remove outdated test for CLI program name and version number

2025-08-09T19:04:38+02:00

The more exhaustive `--version` output parsing tests already assert that
the program name and version number match their expected values.  There
is no point in separately testing this.
</pre>

Ensure that `pytest` picks up the newly-split test modules again

2025-08-09T18:49:50+02:00

If a test module is merely converted to a package, then `pytest` will no
longer pick it up, because the name `__init__.py` does not match the
test module name pattern anymore.  So, rename them.

Also set the `pytest` import mode to `importlib`, as per the
documentation's suggestion.  I haven't had any trouble with this *yet*,
but now I have similarly named modules, so this might otherwise crop up
in the future.
</pre>

Split the CLI tests into one file per class/group

2025-08-09T16:22:42+02:00

The CLI tests, already loosely grouped through the use of classes, are
now distributed to different files, one file per test class.

This is mostly an attempt to keep the file size managable. Navigating in
a multi-thousand-line Python file with very similar looking tests gets
disorienting very quickly.
</pre>

Format and lint all test files

2025-08-09T15:19:17+02:00

</pre>