Refactor CI/CD testing

The automated unit tests would benefit from:

• Cleaning and restructuring
• Migrating appveyor Windows builds to GitHub Actions
• Separating standard tests that are run on every PR and accuracy tests that are run periodically (cron jobs)
• Combine basic API tests on fitted objects to avoid having to call fit multiple times
• Making them importable from other packages (see https://github.com/pytest-dev/pytest/issues/421)
• Making them run on objects rather than classes (see #1027)

[TonyBagnall]

I would like a mapping overview of all the testing that goes on in sktime, then work towards a simple guide to tests, where to put them, what to test for each module etc etc. Improving classifier testing (removing excluded etc) is a mid term goal for me, but its more likely to happen sooner if its easier and intuitive to do

[Lovkush-A]

Been skimming through some of Ted Kaminski’s essays on software engineering, and in this one https://www.tedinski.com/2018/05/01/designing-imperative-code-with-properties-in-mind.html they argue for ‘property testing’ and recommend the package Hypothesis. From hypothesis homepage:

Think of a normal unit test as being something like the following:

• Set up some data.
• Perform some operations on the data.
• Assert something about the result.

Hypothesis lets you write tests which instead look like this:

• For all data matching some specification.
• Perform some operations on the data.
• Assert something about the result.

(Apologies - I realise I am not directly helping with the key steps given in the issue description, but this seems like best place to share knowledge about unittests)