Add unit testing

[JelmerT]

Figure out how to do some kind of unit testing.

This will be pretty complicated since real hardware is probably needed to do all the tests (and there's currently 3 different supported platforms).

[g-oikonomou]

I was thinking of a second script (or number of scripts) that knows how to reply correctly or incorrectly to specific commands.

Edit: The main script ("host") and the device script would talk over FIFOs. This would be sufficient to test everything except serial transport.

We can then put it on travis (?) and perhaps even look into codeclimate. Or maybe I'm just exaggerating now...

[JelmerT]

Travis sounds good to me, I'll have a look if I can set something up.

I also had a second script in mind that basically emulates the boot loader in the different chips. A CC2XXXBootloaderSim so to say.

FIFOs would work, but what do you think about creating a virtual tty via python (http://askubuntu.com/questions/9396/virtual-serial-port-for-testing-purpose) and connecting the bootloader sim to it on one side, and the script on the other side? That way we can test the script closer to 'the real thing'. Not sure if possible, but this way we could test the clock switch a little better (opening the port at a different speed by the script).

I was also thinking, parallel to the sim that we could run on travis, to have a makefile which goes through all the possible scenarios of uploading firmware per platform (as in chip). This then could be used to quickly check the script with real HW connected to a computer.

[g-oikonomou]

FIFOs would work, but what do you think about creating a virtual tty via python (http://askubuntu.com/questions/9396/virtual-serial-port-for-testing-purpose)

That looks very promising!

I was also thinking, parallel to the sim that we could run on travis, to have a makefile which goes through all the possible scenarios of uploading firmware per platform (as in chip). This then could be used to quickly check the script with real HW connected to a computer.

Sounds useful, but I cannot immediately think how we can do this without requiring someone to manually put the device back to bootloader mode between executions.