1. 10 Jan, 2019 1 commit
    • Kirill Smelkov's avatar
      dump, commit: Test for both non-empty and empty transaction extensions · 425e6656
      Kirill Smelkov authored
      Currently we exercise zodbdump and zodbcommit+zodbdump with non-empty
      extensions, which works if ZODB is patched for txn.extension_bytes
      support, but fails on pristine ZODB.
      Support for txn.extension_bytes cannot get into upstream ZODB for
      more than a year:
      and  even if it somehow will make it, it will likely be only in ZODB5,
      while we still care to support ZODB4 and ZODB3.
      Skipping zodbdump / zodbcommit tests, if a ZODB does not have
      txn.extension_bytes support, would result in significant reduction of
      zodbtools test coverage, because practically that is the current
      situation with all upstream ZODB{3,4,5}. Dropping test coverage for
      non-empty extensions is neither a good option.
      For those reason, let's rework the tests and test both zodbdump and
      zodbcommit with two scenarios:
      1. on a test database where transactions extensions are always empty.
         This should work on all ZODB irregardless of whether
         txn.extension_bytes patch is there or not.
      2. on a test database where transactions extensions are present.
         This should work if ZODB has txn.extension_bytes support, but if not,
         we can mark this case as xfail, since the failure is expected.
      This way we make the testsuite pass irregardless of whether
      txn.extension_bytes support is there, and we don't abandon dump/commit
      testing coverage.
      /helped-by Jérome Perrin <jerome@nexedi.com>
  2. 11 May, 2018 1 commit
    • Kirill Smelkov's avatar
      zodbdump: Add golden test · 7f0bbf7e
      Kirill Smelkov authored
      We add a program to generate a test database with all fancy features and
      then check `zodb dump` output on it to golden on.
      The test database itself is commited to git because we want to make sure
      zodbdump works ok for particular exact data and because transaction
      extension dict is potentially saved differently on various runs.
        https://docs.python.org/2.7/library/stdtypes.html#dict.items    and
      """ CPython implementation detail: Keys and values are listed in an arbitrary
          order which is non-random, varies across Python implementations, and depends
          on the dictionary’s history of insertions and deletions. """
      This way on test/gen_testdata.py changes it has to be run manually, and
      then the output result of the run committed back together with
      gen_testdata.py changes.