What's a good way to test individual pieces of hardware?

[AhmedSamara]

Our current set-up is that when we want to test say, the Color_sensor, we have a function and the following statement:

if __name__ == "__main__":
    read_loop()

So that we can just run python color_sensor.py and watch it spit out values onto the command line, but this always involves doing ugly things like copying modules and other folders into the directory we're working from, and it's kind of a headache to deal with.

Is this something that should be handled by unit_tests? I noticed that the unittests all involve simulated hardware, so I'm guessing there's a reason for that, but unless there's a particular reason not to, I'd really like to find a better method than what we've been using.

@dfarrell07 Do you have an opinion on this?

[dfarrell07]

@dfarrell07 Do you have an opinion on this?

As always. ;)

We made design decisions and wrote code exactly for stuff like this.

The "right" way to do it is to expose the code to test the hardware to the API with a lib.api_call decorator. Magic happens (very awesome code), then all you need to do is start the server and a CLI and call your code.

I don't think there's a good way to do hardware tests with unittests. We tried this and never found it helpful. Too failure-prone. The idea with unittests is to validate that all the code works, which should make pretty strong claims about the hardware. Trying to extend them below that becomes very inelegant. If there are issues below the code, my experience is that just running the bot, moving things to see if they work and then debugging via the API works quite well.

[dfarrell07]

copying modules and other folders into the directory we're working from

Anytime you find yourself doing this, there's a very, very good chance you're doing something wrong. I suggest pinging me if you find a situation where this seems like a good idea.

[AhmedSamara]

Also, what was your workflow like when working on the bot?

I've been editing them locally and then rsyncing them onto the bone, but that's kind of annoying to do every time I make a tiny change.

[dfarrell07]

I've been editing them locally and then rsyncing them onto the bone, but that's kind of annoying to do every time I make a tiny change.

That's what I typically do, and I think it's a solid approach. I do the same thing for remote servers every day (I'm normally connected to at least 5 remote boxes all the time).

Do you have your ~/.ssh/config configured to make it easier to get into the bot (and therefore rsync)?

Here's my bit for the bot:

Host bot
    Hostname 10.2.1.1
    User root
    IdentityFile /home/daniel/.ssh/id_rsa_nopass

You'd have to create an SSH keypair if you don't already (with ssh-keygen), and the default name would be id_rsa, not id_rsa_nopass. I use one low-security keypair for stuff like this. It doesn't have a password, so commands like rsync <file I'm working on> bot:<path to file on bot> work without any other input. Additionally, I can typically just arrow-up or !! to get to run that, only typing it the first time.

[dfarrell07]

Oh yeah, and you'd have to run ssh-copy-id to get your keypair onto the bot for that password-less login to work.

[AhmedSamara]

Ah, ok. I was hoping there was some way I could just automatically put it onto the bone if it's plugged in whenever I change something locally. I guess it's minor but the extra-step between writing code and attempting to run it just seems wasteful.

[dfarrell07]

I was hoping there was some way I could just automatically put it onto the bone if it's plugged in whenever I change something locally.

That's certainly not impossible, but I doubt it's worth the effort. Relevant XKCD.

You could script some background task that watches for updates to a file and automatically rsyncs it whenever it sees one, for example. There may also be a way to remotely mount the bone's filesystem, maybe with sshfs.

Again, I'd stick with rsync.

[AhmedSamara]

The "right" way to do it is to expose the code to test the hardware to the API with a lib.api_call decorator. Magic happens (very awesome code), then all you need to do is start the server and a CLI and call your code.

Is there a way to do this with only a part of the bot set up?

Ie: one beaglebone plugged in via USB with only the basic wi-fi dongle for connecting to wi-fi?

I fixed those errors that we used to have where the server used to refuse to build when connecting to the bot anytime hardware was disconnected, but when it's this bare-bones it looks like there are even more problems with it.

[dfarrell07]

I think you'd have to implement this, to allow you to configure subsets of the hardware to run in test mode and other subsets to use real hardware. What I described there, where we assumed we had most of a bot and were just removing a few things, should scale to having a maximally stripped-down setup, like you described.

[AhmedSamara]

This has been solved for a while with the new fine-grained test modes.