Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Compatibility tests between python and C implementations #41

Open
msplr opened this issue Jan 1, 2015 · 11 comments
Open

Compatibility tests between python and C implementations #41

msplr opened this issue Jan 1, 2015 · 11 comments

Comments

@msplr
Copy link
Contributor

msplr commented Jan 1, 2015

We should also test the implementations with each other by additional unit tests.

@antoinealb
Copy link
Member

To repeat what I said:

I would do it by making a C to Python binding to the target code and then write all compatibility tests in python.

That said, I am not sure if it is worth it. It is more into the realm of integration or end to end testing, which have a much lower ROI than unit tests. Since this project is already running late I wonder if it is very wise to do it...

@msplr
Copy link
Contributor Author

msplr commented Jan 1, 2015

I am not sure if it is worth it.

I think it is still better to use python generated data instead of assembling all test data by hand.
We don't have to do it for both ways. Especially the communication from client to target is more complex and should be tested by unit tests.
The test data can be automatically generated and stored as a C include file, containing the raw data and the expected values.

@msplr
Copy link
Contributor Author

msplr commented Jan 1, 2015

I would do it by making a C to Python binding to the target code and then write all compatibility tests in python.

Though, this sounds like much work.

@antoinealb
Copy link
Member

Maybe for those tests it is worth it: https://github.com/cvra/can-bootloader/blob/master/tests/integration_tests.cpp

For other tests I still feel like writing tests in CPP is better, because they are generally simpler and do not contain too much data. This one for example: https://github.com/cvra/can-bootloader/blob/master/tests/datagrams_command_tests.cpp

@msplr
Copy link
Contributor Author

msplr commented Jan 1, 2015

Sure. I don't mean to replace the existing tests, just add at least some tests for python and C interoperability to avoid problems like 97670a4, where the C tests couldn't detect the type problem.
I'm ok with manually generated data, though it would be nice, if it could be done automatically on each test run.

@antoinealb
Copy link
Member

So my preferred approach would be to use ctypes (https://docs.python.org/3.4/library/ctypes.html) and generate a shared library, which would then be called by the python tests. What do you think ?

@31415us
Copy link

31415us commented Jan 2, 2015

@antoinealb ctypes is pretty simple to use. we use it in our beacons library for example, as long as the wrapped api isn't too big or complicated this is probably the best way to go. i could lend a hand if needed (=

@msplr
Copy link
Contributor Author

msplr commented Jan 2, 2015

ok, sounds interesting.
Who'll be doing it?

@antoinealb
Copy link
Member

I can do it.

@antoinealb
Copy link
Member

Although I have to admit I would prefer to move on to further steps in the planning... This is already lagging behind the schedule.

@msplr
Copy link
Contributor Author

msplr commented Jan 2, 2015

Sure, now it's not too important anymore, since we already have hardware to test with. Though for future projects we should do it this way from the beginning.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants