https://git.schokokeks.org/derivepassphrase.git/tree/410e4d5fd537a4041f162990dc08d99b2c26a139 Recent commits feed provided by GitList. (This is part 2 of a series of refactorings for the test suite.) For the basic tests, collect all test data in a common class `Strategies` (similar to the `Parametrize` class). Split them into groups for validity testing and validation/data cleaning. For each group, factor out the common test operation... which in both cases, is the whole test content, save for the different input data set they run on. For the heavy-duty tests, there is only one data generation strategy, which needn't artifically be wrapped in a class (yet). There is also only one test, so there is no need for further grouping either. Instead, add some missing commentary on the one explicit example in that test set. https://git.schokokeks.org/derivepassphrase.git/commit/410e4d5fd537a4041f162990dc08d99b2c26a139 software@the13thletter.info (Marco Ricci) Sun, 17 Aug 2025 16:01:53 +0200 410e4d5fd537a4041f162990dc08d99b2c26a139 (This is part 1 of a series of refactorings for the test suite.) Collect all test data generation strategies in a common class `Strategies` (similar to the `Parametrize` class). Split the tests into groups for debug translations, operations on translatable strings (currently only the hashability check) and suppression of interpolation. Within each group, attempt to factor out common operations, though at the moment, only the debug translations group has code factored out. https://git.schokokeks.org/derivepassphrase.git/commit/6fc85457df65472d6d72e10a99e8f1b2c12b57aa software@the13thletter.info (Marco Ricci) Sun, 17 Aug 2025 15:58:47 +0200 6fc85457df65472d6d72e10a99e8f1b2c12b57aa The existing system of ordinals – loosely modeled on HTTP status codes, but subverted repeatedly because of ad hoc additions or `hypothesis` reimplementations in the test suite – is hopelessly out of sync, and quite an obstacle while refactoring the test suite. Remove them, at least until the test suite is more stable again. On the other hand, there is some value in ordering tests so that – absent any randomization or parallelization of the run order –, the "simpler" or "more fundamental" tests run first: this sometimes provides the needed insight to track down a problem that only manifests in a more cryptic way in the other, more complicated tests. So in the long run, some level of ordering will likely be introduced. But whether this is an ordinal in the test name, or perhaps something more complicated such as a signalling test fixture, or mark, or a custom collection function, or whatever, is still open. https://git.schokokeks.org/derivepassphrase.git/commit/802569dace5b05b0432e07ffbf8118d0de242001 software@the13thletter.info (Marco Ricci) Fri, 15 Aug 2025 18:26:34 +0200 802569dace5b05b0432e07ffbf8118d0de242001 Because the boolean value would otherwise become part of the `pytest` test ID, and because the value is devoid of any context, give each boolean parametrization an explicit, hopefully sensible test ID. https://git.schokokeks.org/derivepassphrase.git/commit/f5a012d44a81ec71b9fca493b4819e531750a5db software@the13thletter.info (Marco Ricci) Fri, 15 Aug 2025 17:59:56 +0200 f5a012d44a81ec71b9fca493b4819e531750a5db Collect, reorganize and reimplement the `hypothesis` strategies for generating phrases and service names in the `vault` module tests. Phrases come in three possible size ranges, are usually binary but sometimes textual (if short), and at times, we explicitly want pairs of phrases that are not interchangable under `vault`, and at other times, we want a second interchangable phrase given a first one. We reimplement the (size-dependent) binary phrase and pair of phrases strategies with `hypothesis.strategies.composite`, and add them to a new namespace of stategies, similar to the `Parametrize` class. I find the result very pleasing to read, and also much more amenable to adjusting the strategies than when the definitions are always included inline. https://git.schokokeks.org/derivepassphrase.git/commit/67c2ee1851ff2ceedee522621611e985b0d47abe software@the13thletter.info (Marco Ricci) Fri, 15 Aug 2025 06:54:29 +0200 67c2ee1851ff2ceedee522621611e985b0d47abe 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. https://git.schokokeks.org/derivepassphrase.git/commit/90a9b2fe873f8df4ab8e3c12ddb71b26d8d23ca3 software@the13thletter.info (Marco Ricci) Fri, 15 Aug 2025 06:51:10 +0200 90a9b2fe873f8df4ab8e3c12ddb71b26d8d23ca3 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. https://git.schokokeks.org/derivepassphrase.git/commit/6a34ef693d7d01335b2799b3429a39250c20bb7c software@the13thletter.info (Marco Ricci) Thu, 14 Aug 2025 22:58:08 +0200 6a34ef693d7d01335b2799b3429a39250c20bb7c 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. https://git.schokokeks.org/derivepassphrase.git/commit/c02db2d55a6d86199adcdbb7c69e31c32a382a89 software@the13thletter.info (Marco Ricci) Thu, 14 Aug 2025 22:47:35 +0200 c02db2d55a6d86199adcdbb7c69e31c32a382a89 Also resolve some TODOs, usually by removing duplicate or quasi-duplicate tests. https://git.schokokeks.org/derivepassphrase.git/commit/d4a4ea165d8a9507807f972f115d624bd73980eb software@the13thletter.info (Marco Ricci) Thu, 14 Aug 2025 20:58:10 +0200 d4a4ea165d8a9507807f972f115d624bd73980eb As in 79e5c37b8eac357c6b5afb6fdcd5e70c0ee3dd43, introduce further classes/groupings for the `vault` derivation scheme tests, trimming test names appropriately. https://git.schokokeks.org/derivepassphrase.git/commit/163550ac08b9e34764b7ea212be85be25fd9cdef software@the13thletter.info (Marco Ricci) Thu, 14 Aug 2025 19:10:17 +0200 163550ac08b9e34764b7ea212be85be25fd9cdef