29.07.18 15:39, Steve Dower пише:
> On 29Jul2018 1253, Serhiy Storchaka wrote:
>> The benefit is that it will be easier to run all C API tests at once,
>> and only them, and it will be clearer what C API is covered by tests.
>> The disadvantage is that you will need to run several files for
>> testing marshal for example.
>
> Can we make the regular tests import and also run the related C API
> tests? So that a normal run wouldn't normally include the entire C API
> test directory, but would include test classes in the related Python
> test modules? (Maybe there's a way to decorate the test classes for this?)
There are many ways of running tests:
./python -m test test_capi
./python -m test.test_capi
./python -m unittest test.test_capi
./python -m unittest discover Lib/test/test_capi/
They need different solutions for making them disabled by default. Seems
that the simplest way is to move test_capi out of the test directory.
But I think that in any case this will complicate testing code.
> I agree with the intent, but also think that's quite a disadvantage. It
> would be good to avoid it.
Actually this disadvantage is not very large. There are not much C API
tests for now.
For now, but if are successful, Serhiy, there will be a lot more tests. 😉
Testing unicode requires running not just test_unicode,
but test_codecs, test_codeccallbacks, test_format, and yet few test.
test_bytes itself is a mess, it needs significant rewriting. Marshal C
API is outdated (it is based on FILE*), it is mostly unused in CPython.
In any case Python tests should be enough for testing Python API.
I think it depends on how you mentally group tests. Do you want to run all tests relating to marshal when you run test_marshal, or should you run test_marshal just for the Python code and test_capi.test_marshal for just the C API depending on what you changed?
One perk of putting the C API tests in under test_capi is it makes it easier for other implementations to ignore those tests if they want to (although I'm assuming all the tests will also be marked as appropriate as CPython-specific).