Bug 79

Summary:	switch to using unittest package for unit testing
Product:	Libre-SOC's first SoC	Reporter:	Jacob Lifshay <programmerjake>
Component:	Source Code	Assignee:	Luke Kenneth Casson Leighton <lkcl>
Status:	CONFIRMED ---
Severity:	enhancement	CC:	libre-soc-bugs
Priority:	---
Version:	unspecified
Hardware:	All
OS:	All
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:

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.