Those methods are typically implemented by abstract
super classes, in particular via categories, in order to
enforce standard behavior and API, or provide mathematical
sanity checks. For example if self is in the category of
finite semigroups, this checks that the multiplication is
associative (at least on some elements):

Debugging tip: in case of failure of some test, use %pdbon to
turn on automatic debugging on error. Run the failing test
independtly: the debugger will stop right where the first
assertion fails. Then, introspection can be used to analyse what
exactly the problem is. See also the catch=False option to
run().

When meaningful, one can further customize on which elements
the tests are run. Here, we use it to prove that the
multiplication is indeed associative, by running the test on
all the elements:

sage: S._test_associativity(elements=S)

Adding a new test boils down to adding a new method in the class
of the object or any super class (e.g. in a category). This method
should use the utility _tester() to handle standard options
and report test failures. See the code of
_test_an_element() for an example. Note: Python’s testunit
convention is to look for methods called .test*; we use instead
._test_* so as not to pollute the object’s interface.

Eventually, every implementation of a SageObject should
run a TestSuite on one of its instances in its doctest
(replacing the current loads(dumps(x)) tests).

Finally, running TestSuite on a standard Python object does
some basic sanity checks:

Don’t catch the exceptions if TestSuite(..).run() is called
under the debugger, or with %pdb on (how to detect this? see
get_ipython(), IPython.Magic.shell.call_pdb, ...)
In the mean time, see the catch=False option.

Run the tests according to the inheritance order, from most
generic to most specific, rather than alphabetically. Then, the
first failure will be the most relevant, the others being
usually consequences.

Integration with unittest:
Make TestSuite inherit from unittest.TestSuite?
Make .run(...) accept a result object

Add some standard option proof=True, asking for the
test method to choose appropriately the elements so as to
prove the desired property. The test method may assume that
a parent implements properly all the super categories. For
example, the _test_commutative method of the category
CommutativeSemigroups() may just check that the
provided generators commute, implicitly assuming that
generators indeed generate the semigroup (as required by
Semigroups()).