Permit replacement of pin_factory without closing old factory. However,
continue closing devices associated with extant pin factory at script
termination.
Wrong classname in the software implementation and for some reason I'd
reverted a change on spi_flags somewhere... Also removed the clause
skipping remote pigpiod tests
Tested this commit with hardware and software SPI remotely - working
nicely
Also renamed GPIOZERO_INPUT_PIN to GPIOZERO_TEST_INPUT_PIN, and fixed up
the pigpio factory so it actually raises an exception if the connection
fails and we don't try and control the daemon anymore.
The real pin tests were broken by the new factory stuff. This commit
fixes them up, and fixes up a few other bits besides (like why the
pigpio PWM tests were failing, why RPi.GPIO sometimes segfaulted on PWM
tests, etc.)
It also causes the real pin tests to run against MockPin (thanks to
@lurch for the suggestion!). This required some tweaks to MockPin to
make it emulate physically pulled up pins itself (which in turn
necessitated changing quite a few pin numbers in the main test suite
because we were using 2 and 3 everywhere), and to allow one MockPin to
drive another. Anyway, everything's working now including all the tests
on a Pi (haven't tried RPIO yet, but only because I'm on a Pi3 -
everything else works with overall coverage of 88% :).
Also re-numbers energenie sockets 1-4 (as noted by @bennuttall in
comments to #239), and adds several "real pins" tests and board tests.
The bad-PWM stuff is currently disabled as it causes segfaults when
running the tests and I can't seem to trace the cause at the moment.
Finally, I've tweaked the deb config to suggest gpiozero, removed spidev
as a mandatory dep (which'll fix installs on wheezy for py3), and
there's some more miscellaneous last-minute stuff here that I can't
recall...
This is just a quicky for people to start playing with - it's not
complete in any way, shape, or form. This is how I envisage the "real"
pin tests being done; part of the test suite with a `skipif` to ensure
they don't get run on non-Pi platforms, with a fixture to loop over
whatever pin implementations are found (we can't always assume all of
them: for example, RPIO doesn't work on a Pi 2), and a relatively simple
wiring for the test.
In this case I've assumed GPIOs 22 and 27 are wired together. They're
next to each other, so a jumper is sufficient to run the test.
PRs extending the coverage are very welcome (I've already discovered and
fixed several silly bugs in NativePin!). I've left all the interesting
hard stuff for people to play with (PWM testing: statistical sampling?
debounce compensation testing: timing?). When I've got a second, I'll
looking into hooking up my Pi Zero as a Travis-esque test-bed for this,
triggered by GitHub webhooks (not sure how I'll deal with reporting
yet).
