Bug 79 - switch to using unittest package for unit testing
Summary: switch to using unittest package for unit testing
Status: CONFIRMED
Alias: None
Product: Libre-SOC's first SoC
Classification: Unclassified
Component: Source Code (show other bugs)
Version: unspecified
Hardware: All All
: --- enhancement
Assignee: Luke Kenneth Casson Leighton
URL:
Depends on:
Blocks:
 
Reported: 2019-04-30 03:59 BST by Jacob Lifshay
Modified: 2019-04-30 12:13 BST (History)
1 user (show)

See Also:
NLnet milestone: ---
total budget (EUR) for completion of task and all subtasks: 0
budget (EUR) for this task, excluding subtasks' budget: 0
parent task for budget allocation:
child tasks for budget allocation:
The table of payments (in EUR) for this task; TOML format:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jacob Lifshay 2019-04-30 03:59:32 BST
I think it would be better to use Python's built-in unittest package instead of using our own custom unit testing framework.

https://docs.python.org/3/library/unittest.html

It supports things like:
* finding all test*.py files and loading them automatically
* allowing filtering of which tests are run without needing to comment out sections of the source code
* being a well-known unit testing framework
* has a test-running GUI for those who don't like command-line as much
* not needing a Makefile
Comment 1 Luke Kenneth Casson Leighton 2019-04-30 12:13:35 BST
yes, i know, things have been thrown together somewhat, and
need sorting out.

i have a personal preference for using a Makefile even as
a shortcut / substitute for running a single command,
"nosetests3" or "python3 setup.py test".

test:
    nosetests3

it provides a central standardised location, and some uniformity
that makes more sense for more complex tasks (installation etc.)

i also tend to put in things like "make docs":

docs:
    epydoc -blahblah

which has sufficiently complex options that i tend to forget what they are.
likewise with autopep8, there are some options that *need* to be disabled.

etc. etc. otherwise you end up with a total mess of disparate "scripts"
and force the developer to go read some arbitrary text file to find out
what they are.