For the netstat action there really isn’t much to do since it’s a straight remote-shell-cmd action, and it only has a single user-specified parameter, args. So this one probably doesn’t need a unit test.

Same story for the cp, mv, netstat_grep, pkill, rm, rsync, scp, and vmstat actions.

I’m a little confused why the file_touch action doesn’t use the touch command…that could probably be changed, but if you do I would rename the existing file_touch action to something like file_init.

For the service action, it’s a remote-shell-script but it’s actually a Python script, so you can probably import directly from it, mock up and monkeypatch the sys and subprocess modules in it, and then assert that the right command arguments are passed to subprocess.call.

check_loadavg needs some tests, I would mock up and monkeypatch loadAvgFile and cpuInfoFile, override sys.stdout and check its output. Once you’ve got some tests, it then needs to be updated to support both Python 2 and 3 (except Exception:).

check_processes needs tests - you don’t need to test every method, but I would test at least byState, byPid, and byName. First, choose a pid number and set the action instance's myPid property to it, then create a test fixture directory that contains directories with purely numeric names, a few with non-numeric names, and a name that matches your chosen myPid number (say: 3456. Make sure you put stat and cmdline files in each pid directory:

proc_fixture/
proc_fixture/1234/
proc_fixture/1234/stat
proc_fixture/1234/cmdline
proc_fixture/2345/
proc_fixture/2345/stat
proc_fixture/2345/cmdline
proc_fixture/3456/
proc_fixture/3456/stat
proc_fixture/3456/cmdline
proc_fixture/abcd/
proc_fixture/abcd/stat
proc_fixture/abcd/cmdline
proc_fixture/4567/
proc_fixture/4567/stat
proc_fixture/4567/cmdline

Set the procDir property to your fixture directory, override sys.stdout and check that against a known value.

For wait_for_ssh, we need to check two of the three use cases: (1) unconnectable host (SSH timeout), and (2) instantly connectable host (eg: localhost). Use test_action_dig.py as a template for this.

If you need help standing up a test environment to begin with, I would dig through the Travis config and rerun the same commands in a VM.