Pythoscope does not detect conflicts caused by naming convention used for tests.
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Pythoscope |
Confirmed
|
Medium
|
Unassigned |
Bug Description
environment: windows, python 2.5, pythoscope 1.4.2
test case in attachment
log:
E:\projects\
INFO: Inspecting module my\cool_class.py.
INFO: Inspecting module my\__init__.py.
INFO: Inspecting module my_cool_class.py.
E:\projects\
INFO: my\cool_class.py hasn't changed since last inspection, skipping.
INFO: my\__init__.py hasn't changed since last inspection, skipping.
INFO: my_cool_class.py hasn't changed since last inspection, skipping.
INFO: No changes discovered in the source code, skipping dynamic inspection.
INFO: Generating tests for module my_cool_class.py.
INFO: Adding generated TestA to tests\test_
INFO: Generating tests for module my\__init__.py.
INFO: Generating tests for module my\cool_class.py.
INFO: Adding generated TestB to tests\test_
INFO: Test case TestA.test_member3 already exists in tests\test_
, skipping.
Both modules my_cool_class and my.cool_class will end up trying to build a test called test_my_cool_class but
Pythoscope does not detect the conflict.
The result is that the test class contains some tests for both modules and misses some of whatever module happens to come 2nd.
The case may seem a bit contrived but will (and has) crop up when refactoring prefixed code to proper modules for instance.
Proper handling of this case may require a bit of work, but flagging the problem would already improve the situation.
Changed in pythoscope: | |
milestone: | none → 0.5-usability |
Thank you for pointing this one out! Bug #475504 is related, but it talks about test cases at the test method level, and I totally forgot about conflicts at the package/module level.
OK, so we have a package "my" with a module "cool_class" and a module "my_cool_class". Should their test land in the same test module? Maybe, their names are related. If not, how should they be named? And, the most important question, can pythoscope figure those things out reliably in all situations?
I'm thinking, maybe a bit of configuration would work as a solution to this problem? If there was a file where you could map application modules to test modules (like "my/cool_class => legacy_ my_cool_ class_test" ) that would allow pythoscope to use conventions by default and still allow a developer to override those when needed. What do you think, is that a good solution to this problem?