2009/11/23 Michal Kwiatkowski <email address hidden>:
> 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.
Since pythoscope can't really tell if they're related entities, it
act as if they are not related. It's the way of least surprises.
> If not, how should they be named?
As long as pythoscope flattens the names, there will always be conflicts.
Is there a fundamental reason why pythoscope should not use packages
or subdirectories for tests?
> And, the most
> important question, can pythoscope figure those things out reliably in
> all situations?
It can, by keeping track of the difference between packages and modules.
This may be related to the work you planned for 1.5
Once projects start to have non-trivial amounts of test cases, you'd
want a way to group them anyway.
> 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?
* Configurations may lead to new name conflicts and pythoscope still
doesn't help in detecting them.
* The configuration work-around doesn't scale well to teams doing
parallel development as name conflicts can be (silently) introduced
(by another team for instance) when you thought you were safe.
Also, I don't think it's nice if tools cause trouble and then ask
their users to solve it for them ;-)