Best way for plugin checks

OllisGit · April 17, 2021, 7:46am

Hi,

in the past (and maybe also in the future) I made similar errors:

forgot to add new class files to github, but import statement is there
call unknown methods, because I renamed it
...other stupid thinks, like wrong type casting, missing not None checks, ....

Of course writing Python-Tests and execute before build is always a good idea, but if you forgot to write tests for the new class you have the same error.

I did a short test with mypy, but received some errors related to OctoPrint (beside my own)

mypy --py2 .

setup.py:52: error: Need type comment for 'plugin_additional_data' (hint: "plugin_additional_data = ...  # type: List[<type>]")
setup.py:72: error: Skipping analyzing 'setuptools': found module but no type hints or library stubs
setup.py:75: error: Cannot find implementation or library stub for module named 'octoprint_setuptools'
setup.py:102: error: Cannot find implementation or library stub for module named 'octoprint.util'
...
octoprint_PrintJobHistory/__init__.py:7: error: Cannot find implementation or library stub for module named 'octoprint.plugin'
octoprint_PrintJobHistory/__init__.py:7: error: Cannot find implementation or library stub for module named 'octoprint'
octoprint_PrintJobHistory/__init__.py:8: error: Cannot find implementation or library stub for module named 'octoprint.events'

How do you test your plugins in an automatic way?

Charlie_Powell · April 17, 2021, 8:05am

There's several things you can do to test, some of which are not automatic and some are. I personally like automatic things, such as pre-commit and tests, but a wider testing audience can help massively.

Writing Python tests ensures that the modules can be imported properly, so if you forget to add referenced files before a release then it will automatically fail on the import error. I added some unit tests for a few plugins, for example here in Marlin EEPROM editor:

github.com

cp2004/OctoPrint-EEPROM-Marlin/blob/e62437eafc1d3b40e2bcc8e4bd010adcc6287d66/tests/test_parser.py

# -*- coding: utf-8 -*-
import unittest

import mock

from octoprint_eeprom_marlin import parser


class ParserTestCase(unittest.TestCase):
    def test_regex_command(self):
        test_cases_command = {
            "echo: M92 X80.0 Y80.0 Z800.0 E90.0": "M92",
            "echo: M203 X400.0 Y400.0 Z5.0 E25.0": "M203",
            "echo: M201 E74.0 X2000.0 Y2000.0 Z10.0": "M201",
        }

        for test, result in test_cases_command.items():
            match = parser.regex_command.match(test)
            self.assertEqual(match.group("gcode"), result)

This file has been truncated. show original

You could add a very simple test case that just imports all the known classes of your plugin to make sure they don't import things that don't exist.

The other thing I strongly recommend you do, is use a pre-release channel to get other people to test the plugin as well. It has worked very well for many of us and is configurable in the OctoPrint Software Update UI.

Here's a guide on how to add a 'Release Candidate' channel to your plugin:

github.com

cp2004/OctoPrint-Knowledge/blob/a151c99e4b5e3a5680407874922d34c14e9d4642/release-channels.md

## How to add release channels to your OctoPrint plugin

Release channels are very helpful to get people to test new functionality, commonly through the well-known 'release candidate'

Adding release channels to OctoPrint has existed for a while now, but until OctoPrint 1.5.0 they were not configurable from the UI, so nobody used them.

Here's a guide detailing 'how to add a release channel', and then how to publish releases utilising them afterwards!

### Configuring your plugin's Software Update hook

1. Find the current SW update hook, looks something like this:
   ```python
   def get_update_information(self):
        return {
           "eeprom_marlin": {
               "displayName": "Marlin EEPROM Editor",
               "displayVersion": self._plugin_version,
               # version check: github repository
               "type": "github_release",
               "user": "cp2004",

This file has been truncated. show original

That means you only roll out the plugin to a small number of people, recommend people who have reported bugs or requested features to test it - they usually do, since there is an incentive to do so.

OllisGit · April 17, 2021, 8:18am

Thank you very much for your feedback!

A simple testclass with just imports it is a clever idea, I will do that.
The "release channel" thing is already on my list.

There is a german phrase: "No time to sharpen the Axe, I need to chop wood."....but now it is the time for sharpen the axe

jneilliii · April 17, 2021, 7:20pm

That is a great quote @OllisGit and thanks for the quick merge on Spool Manager.