Skip to main content

Uji - checklist generator and tracking system

uji is a tool to generate checklists from template files and hold on to those lists forever or until the cows come home, whichever happens later.

uji is useful for cases where a user has

  • large checklists with overlapping items, e.g. the same sets of test to be performed on different hardware
  • the checklists are recurring, e.g. they need to be performed on every package update
  • not all checklist items will be ticked every time but the user needs to remember which ones were ticked off
  • there is other free-form information to be stored alongside the checklists

The main purpose of uji is to simplify the answer to "Wait, didn't I test this?"

  • uji is not a todo list
  • uji is not a test suite
  • uji is not something you can integrate into a CI

If you have a test that can be automated, uji is not the right tool. uji is to track manual tests that cannot be automated. If you want to generate test summaries, uji is not the right tool. uji tracks manual tests.

uji is optimized for writing, not reading. 99% of the logs tracked with uji will never be read. Hence uji is built for minimal friction to write the tests - basically you need git, python and an editor. The central file is a markdown text file that you can edit and annotate (almost) at will. It's all stored in git, so backup, sharing, and collaboration is trivial. It's markdown, so you push the file anywhere (gitlab, github, ...) and it'll probably look nice in the browser.

uji just preps the file for you and (in the future) provides a set of CLI tools to automate some tasks around maintaining the test files.

"uji" is Indonesian for "test".

Use case

Upgrading software packages usually requires multiple manual tests. Ideally you have a checklist to tick off the things you tested. Next time you upgrade that same package, the same checklist applies. Ideally you tick off all the checklist items every time but we both know you don't. Maybe hardware is missing, or the moon phase is wrong for tedious work, or, well, so many reasons.

And then suddenly, a few months later a bug reports appears. And now the question is: "wait, didn't I test this?"

And uji should be able answer that question.

How it works

The core of uji is a set of test templates in YAML format. These templates are combined to a full test document (in markdown) on invoking uji new. That file together with the log files required for the various tests are stored in a git tree. As the tests are performed the user ticks them off in the .md file and eventually commits them to git.

The next test run does the same, uji new creates a new directory, rinse, wash, repeat.

So when the question "did I test this?" arises, you can go back, check the respective log set and check - is the box for that test ticked off? And if it is and it's still broken - well, you should have the various log files in that same directory to figure out where the differences are.

None of this is novel of course, uji is just a commandline wrapper to make that proces simpler.

Usage

Look at the example.yaml file for an example test configuration.

$ mkdir my-test-results && cd my-test-results
$ git init
$ wget -o mypackage.yaml https://raw.githubusercontent.com/whot/uji/master/examples/example.yaml

Now you're set up. Edit the mypackage.yaml file and add your tests. Once ready, git commit mypackage.yaml because you want this to be preserved.

And when you're ready to start a test run:

$ cd my-test-results
$ uji new mypackage.yaml
Your test records and log files are
  mypackage-2019-12-10.0/
  mypackage-2019-12-10.0/logitech_keyboard
  mypackage-2019-12-10.0/t450_keyboard
  mypackage-2019-12-10.0/t460_keyboard
  mypackage-2019-12-10.0/example.md
  mypackage-2019-12-10.0/example.yaml
  mypackage-2019-12-10.0/logitech_g500s
  mypackage-2019-12-10.0/macbook_keyboard
  mypackage-2019-12-10.0/logitech_mx_anywhere_2s
  mypackage-2019-12-10.0/logitech_keyboard/test_hotplug_libinput
  mypackage-2019-12-10.0/logitech_keyboard/test_usb_logs
  mypackage-2019-12-10.0/logitech_keyboard/log_input_devices
  mypackage-2019-12-10.0/logitech_keyboard/test_hotplug_libinput/dmesg
  mypackage-2019-12-10.0/logitech_keyboard/test_usb_logs/lsusb −v
  mypackage-2019-12-10.0/logitech_keyboard/log_input_devices/libinput record −−all
  mypackage-2019-12-10.0/logitech_keyboard/log_input_devices/∕proc∕bus∕input∕devices
  mypackage-2019-12-10.0/t450_keyboard/log_input_devices
  mypackage-2019-12-10.0/t450_keyboard/log_input_devices/libinput record −−all
  mypackage-2019-12-10.0/t450_keyboard/log_input_devices/∕proc∕bus∕input∕devices
  mypackage-2019-12-10.0/t460_keyboard/log_input_devices
  mypackage-2019-12-10.0/t460_keyboard/log_input_devices/libinput record −−all
  mypackage-2019-12-10.0/t460_keyboard/log_input_devices/∕proc∕bus∕input∕devices
  mypackage-2019-12-10.0/logitech_g500s/log_input_devices
  mypackage-2019-12-10.0/logitech_g500s/log_input_devices/libinput record −−all
  mypackage-2019-12-10.0/logitech_g500s/log_input_devices/∕proc∕bus∕input∕devices
  mypackage-2019-12-10.0/macbook_keyboard/test_usb_logs
  mypackage-2019-12-10.0/macbook_keyboard/log_input_devices
  mypackage-2019-12-10.0/macbook_keyboard/test_usb_logs/lsusb −v
  mypackage-2019-12-10.0/macbook_keyboard/log_input_devices/libinput record −−all
  mypackage-2019-12-10.0/macbook_keyboard/log_input_devices/∕proc∕bus∕input∕devices
  mypackage-2019-12-10.0/logitech_mx_anywhere_2s/log_input_devices
  mypackage-2019-12-10.0/logitech_mx_anywhere_2s/log_input_devices/libinput record −−all
  mypackage-2019-12-10.0/logitech_mx_anywhere_2s/log_input_devices/∕proc∕bus∕input∕devices
Run "git commit" to commit the changes, or "git reset" to throw them away
$ git commit -am 'mypackage: new test log set'
$ vim mypackage-2019-12-04.0/mypackage.md
# tick off the tests as you confirm them

$ cp /proc/bus/input/devices mypackage-2019-12-10.0/logitech_keyboard/log_input_devices/∕proc∕bus∕input∕devices
$ lsusb &> mypackage-2019-12-10.0/macbook_keyboard/test_usb_logs/lsusb −v

# copy the other files into the right file names

$ git commit -am 'mypackage: test log set done'

And that's it for now.

License

uji is licensed under the MIT license. See LICENSE for more info.

Download files

Download the file for your platform. If you're not sure which to choose, learn more about installing packages.

Source Distribution

uji-0.1.tar.gz (15.8 kB view details)

Uploaded Source

Built Distribution

If you're not sure about the file name format, learn more about wheel file names.

uji-0.1-py3-none-any.whl (17.4 kB view details)

Uploaded Python 3

File details

Details for the file uji-0.1.tar.gz.

File metadata

  • Download URL: uji-0.1.tar.gz
  • Upload date:
  • Size: 15.8 kB
  • Tags: Source
  • Uploaded using Trusted Publishing? No
  • Uploaded via: twine/1.13.0 pkginfo/1.4.2 requests/2.22.0 setuptools/41.2.0 requests-toolbelt/0.9.1 tqdm/4.37.0 CPython/3.7.5

File hashes

Hashes for uji-0.1.tar.gz
Algorithm Hash digest
SHA256 ad0d4b80ac9d1e79e6c2b7cf5d2883ec4d628939ebc927e9f8317b2dc5afef8c
MD5 f193ba40439180135d59cedb200e1bc6
BLAKE2b-256 1b6172d236f19f8dc6d75204ee85c980c0d0719fb283cc2d3571f60f868d3627

See more details on using hashes here.

File details

Details for the file uji-0.1-py3-none-any.whl.

File metadata

  • Download URL: uji-0.1-py3-none-any.whl
  • Upload date:
  • Size: 17.4 kB
  • Tags: Python 3
  • Uploaded using Trusted Publishing? No
  • Uploaded via: twine/1.13.0 pkginfo/1.4.2 requests/2.22.0 setuptools/41.2.0 requests-toolbelt/0.9.1 tqdm/4.37.0 CPython/3.7.5

File hashes

Hashes for uji-0.1-py3-none-any.whl
Algorithm Hash digest
SHA256 ea0c892e5e56ae556ebe79f2e30051f398e8bd4bc13d24c8a01cc096c7055ceb
MD5 7e7f2f57a4e6b1180b4bf334e8618564
BLAKE2b-256 83bec650d0d3cea1e36a6e47afbc8718a3aa978f28f34367ee7a84d6012b1119

See more details on using hashes here.

Supported by

AWS Cloud computing and Security Sponsor Datadog Monitoring Depot Continuous Integration Fastly CDN Google Download Analytics Pingdom Monitoring Sentry Error logging StatusPage Status page