Define an api module

[goanpeca]

The idea for the new api decoupling is that every plugin on spyder (even third party) or at least the one we make, should include an api module and define there any public api we want to expose.

Since this is a language related plugin, I need to brief you a bit on how I think we can handle that.

But so far we need to have a language agnostic functionality assuming that a unit test suite gives a list of tests (failed, passed, xfailed, xpassed) plus some optional coverage.

[jitseniesen]

It's not quite clear to me how this will work, so I will wait until you converted at least one other plugin 😉 Should the interface between Spyder and the plugin be part of the api module? I'm finding it hard to think of a use case where another plugin needs to interface with this plugin.

Running tests takes a while so the API needs to be asynchronous.

The plugin is actually almost language agnostic. The Python specific parts are the definition of the different testing frameworks (py.test, nose, unittest, etc., though only the first one works at the moment) and some special handling of pythonpath.

Implementation of coverage is still quite far off.

[goanpeca]

It's not quite clear to me how this will work, so I will wait until you converted at least one other plugin 😉 Should the interface between Spyder and the plugin be part of the api module? I'm finding it hard to think of a use case where another plugin needs to interface with this plugin.

Agreed, I am still working on that proposal to get feedback. But the general idea is that all plugins will have an api and that is point of extension.

For a basic idea you can look at https://github.com/spyder-ide/spyder/wiki/API-decoupling

Running tests takes a while so the API needs to be asynchronous.

Sure, we need to have a runner/worker for this...

The plugin is actually almost language agnostic. The Python specific parts are the definition of the different testing frameworks (py.test, nose, unittest, etc., though only the first one works at the moment) and some special handling of pythonpath.

The general idea is to define the basic agnostic api and a Manager that will take care of the registration of new languages.

I would even say that since this is something of common use, I would make the generic parts part of spyder and only define the specific python ones either in this package, or as part of the

spyder_python package (that will by default be part of spyder).

So if someone want to create an extension of this plugin for another language they use the api.

from spyder.api import unit_test

class SomeOtherLanguage(unit_test.BaseWidget):
   def some_common_use_api(self):
       pass

api.unit_test.register(R', SomeOtherLanguage)

The available languages should come from the spyder API, so that we are sure we give gradual support.

[goanpeca]

Another option would be to leave this as a separate package that defines the two submodules

spyder_unitest
    spyder_unitest
    spyder_unittest_python

Or something

[jitseniesen]

My plan was for the widget to be agnostic, and to define a TestRunner class for every test framework (that's what #9 is about):

class BaseTestRunner(QObject):
    sig_test_results = Signal(something)
    def run_tests(basedir):
        """Run tests and emit sig_test_results with results as they come in."""
        raise NotImplementedException

The plugin would then define subclasses for every unit test framework. That should be quite easy to combine with register() as you propose; the main thing to keep in mind is that a programming language will have multiple test frameworks.

[goanpeca]

Awesome, yes this is the general idea :-) looks good. Sure we need to register language and test framework...

So either the TestRunner defines a class variable with the info, or that is provided upon registry :-)