search

rwaldron / io-plugins

Documentation and discussion point for IO Plugins
117 stars 21 forks source link

Test suite #2

Open jcrugzz opened 9 years ago

jcrugzz commented 9 years ago

Just seeing this and I think its awesome! I only wanted to link to a couple things that I think could make this super successful. Providing an abstract test suite has been a really good approach for abstract-blob-store and abstract-leveldown to ensure the interface is met programmatically. Basically it would be a test based version of what you have documented here. Anyways, keep up the great work with the nodebots community!

rwaldron commented 9 years ago

+1

Here's some bits and pieces if anyone wants to do this:

nebrius commented 9 years ago

I have been rolling an idea around in my head for a while now to implement at least some of this for raspi-io. I feel that implementing I2C for the RPi is complicated enough that I'm want to do full on TDD for it. I figure might as well create a proper abstract suite for it.

I foresee this being more of a library, say test-io, that each IO plugin would pass in a configuration to saying "these are the GPIOs, these are the PWMs, these are the I2Cs, etc". This would run on a laptop for all devices, regardless of whether or not the io plugin is self-hosted. Let's call this the server. This would be the piece running nodeunit, etc.

The server would then talk to an Arduino over UART with a custom-designed shield that does pin coalescing and level translation running some custom C code that is connected to the device in question (Raspberry Pi in my case). Let's call this the tester. The server will tell the tester "run test x with parameters y". Long term this would ideally be able to handle GPIO both ways, PWM (have the Arduino perform timing analysis to verify period/duty cycle), I2C, SPI, UART, and so on. I think that testing on device is necessary because I have uncovered bugs that were only visible on real hardware (permissions issues, incorrect clock register values, etc).

The server would also talk to a node instance somewhere (over HTTP, websockets?) that runs the IO plugin code. This would work similarly to the tester code, except written in Node.js.

In time, these pieces could grow such that the server can coordinate the tests for multiple clients/testers, allowing, for example, me to test all of the different revisions of the Raspberry Pi simultaneously (we're up to 6 different versions now!)

Thoughts?