Add more sensor and motor types?

[WasabiFan]

Currently there're an IR sensor and a medium motor here. Can we add some others so that we can test device-specific functionality?

I'm imagining that we could have folders for the different types of available sensors and motors separate from the driver folders, so that in test scripts we would copy the devices that we wanted into the proper driver directory and clear that directory when finished. This has the added benefit that you can always just delete everything in the driver folders (e.g. lego-sensor) to clean it, because we would never modify the originals.

This makes the system more complex, however; if we want to make it more complex like this we might actually need helper scripts in this repo that take in the devices you want and what index they should be put at and configures the folders accordingly. That should work with just a simple 10-line Python script, so not too complex.

Whatever the case, I'm going to be getting tests implemented in my lib when I get the chance.

[WasabiFan]

also should notify @rhempel as he isn't yet watching this repo.

[ddemidov]

Can we add some others so that we can test device-specific functionality?

Sure, do you have anything specific in mind? I've also added a README documenting the way I copied the files, so making a PR should be easy :). Or I could add you and @rhempel as contributors.

I'm imagining that we could have folders for the different types of available sensors and motors separate from the driver folders, so that in test scripts we would copy the devices that we wanted into the proper driver directory and clear that directory when finished. This has the added benefit that you can always just delete everything in the driver folders (e.g. lego-sensor) to clean it, because we would never modify the originals.

That could be a good idea, especially since I've been avoiding any tests both in python and in C++ that would modify the fake /sys contents in order to keep the git status clean and the tests reproducible.

This makes the system more complex, however; if we want to make it more complex like this we might actually need helper scripts in this repo that take in the devices you want and what index they should be put at and configures the folders accordingly. That should work with just a simple 10-line Python script, so not too complex.

I guess a simple procedure of

• copy next device (or devices, if the test needs it) to the fake /sys/class;
• run the test;
• clean up

should do. So a couple of simple bash (or python, whatever is more portable) scripts should be enough.

[WasabiFan]

Sure, do you have anything specific in mind?

Ideally, I'd want one for each of the custom sensor classes (and a version for each sensor class in each mode) as well as one for the DC motor, because that one's a bit different from the normal tacho motors. But that is a lot of work if we wanted all the permutations of sensors and modes (and it brings very little benefit), so I'd say this:

• DC motor
• Touch sensor
• Ultrasonic sensor in CM mode
  • Can test to make sure that it sets the ultrasonic sensor to inches mode when you read for inches

Is there any coverage you think we'd be missing there?

I've been avoiding any tests both in python and in C++ that would modify the fake /sys contents in order to keep the git status clean and the tests reproducible.

That's a big :+1: in my mind for using this system and copying the devices in as needed. It'll let us test automatic mode changes, writing to selector properties, etc.

I guess a simple procedure of...

Yeah, that seems right.

So a couple of simple bash (or python, whatever is more portable) scripts should be enough.

Although I don't think there are any perfect options, I'd vote for pretty much anything but bash (unless it's very portable), given that I do most (if not all) my development on Windows. Dealing with running tests in Cygwin or something is just not fun. But Python should be fine. Another option would be Node as we already need it at the moment for the autogen, but Node isn't very powerful in the file manipulation area so I'd say just stick with Python.

Basically, I'm just imagining this:

# Before test case
$ clean-test-area.py
$ add-test-device.py ir-sensor 0 # Add sensor from the folder ir-sensor with the index sensor0

# After all test cases (to clean git diff)
$ clean-test-area.py

And actually, looking at that, we might be able to write a script that runs in both CMD and bash. But that's pretty limiting and could get painful.

[ddemidov]

DC motor, Touch sensor, Ultrasonic sensor in CM mode

Of those three, I only have touch sensor (I just own home set 31313), so please add the rest if you can. I think we can cover basic functionality with those. And since most of our bindings is autogenerated, that should be enough.

After all test cases (to clean git diff)

If we add the test area to .gitignore, then this won't be a concern. But cleaning is good :). I was having in mind something like this:

$ run-test.py -d motor0 -d motor1 -t test-pair-of-motors

run-test.py would copy the specified devices to the arena, run the specified test, clean up and exit with exit status of the test.

[WasabiFan]

Of those three, I only have touch sensor (I just own home set 31313), so please add the rest if you can.

I can tomorrow; I'll be in transit for the next 9 hours, and although I do have my EV3 and some sensors with me I don't think they would be happy with me taking it out on the plane :wink: I'll open a PR when I can.

I was having in mind something like this...

I see two issues with doing it this way:

• If there are special interfaces that tests for a particular language can use (task runners, IDE integration, etc.) it won't work if it is wrapped in another script
• We would need to modify the Python script in this repo when we want to change the testing mechanism or add a new language

[ddemidov]

I can tomorrow;

There is no rush :).

If there are special interfaces that tests for a particular language can use (task runners, IDE integration, etc.) it won't work if it is wrapped in another script

I can provide both options (head/tail scripts and the wrapper script).

[WasabiFan]

If we add the test area to .gitignore , then this won't be a concern.

I see a minor issue here... git tracks content, not files. So we will need the script to create the driver folders.

---

And also, one of the functions that the script serves will need to be setting the address of the devices it creates.

[ddemidov]

We would need to modify the Python script in this repo when we want to change the testing mechanism or add a new language

I am not sure I follow.

$ run-test.py -d motor0 -d motor1 -t test-pair-of-motors

Here motor0 and motor1 are just paths to the folders to be copied, and test-pair-of-motors is just an executable to launch (possibly with parameters). This sounds completely language-agnostic to me.

[WasabiFan]

This sounds completely language-agnostic to me.

I see -- so we'd have a shell script or other executable for each test that this would execute. That makes sense. I'd personally still prefer the "utility methods" approach instead of the "test runner" version, but it sounds like it should be pretty easy to implement both so we can do it however it makes the most sense for that language. Sounds good!

[ddemidov]

I've updated tests in C++ repo to use the functionality (https://github.com/ddemidov/ev3dev-lang-cpp/commit/de8c5d4dd6f8d2ebe7563b83a97bd3c737294608). It works!

[WasabiFan]

Cool! I got started with tests using this system on my end, but won't be able to finish now... In my time zone it's currently 1:00 in the morning and I need to sleep :wink: