Mar 20, 2014 at 7:03 PM
Edited Mar 20, 2014 at 7:04 PM
I see. The examples given in the unittest documentation are restrictions compared to what PTVS does - we already look at all files in the project regardless of name. We don't really want to maintain yet-another-list-of-paths that reference test files -
there's already enough of a mess with environments/search paths/references/etc.
The best way to approach this in PTVS is to create another .pyproj file for your tests and have two projects in your solution (i.e. have them both open at once). If you add a search path from the test project back to the main project, all the tests should work
just as well as if they were in the same project.
Another approach that could be used is to create a test in your project that runs the third-party test. Deriving from another test class should make all of the tests visible (provided they also appear in IntelliSense - we use the same code analysis to find
tests). Something like:
class TestWrapper(unittest.TestCase, ThirdPartyTestClassWithTests):
should work, but you could also redirect to individual tests with
def test_a(self): ThirdPartyTestClassWithTests.runtest_a(self)
if that naming convention needs fixing.
Neither us nor the unittest options let you configure the method name prefix (and we currently don't detect
based tests, which is a separate issue), so I don't think anything would be gained here.
It may be interesting to try and handle the @skip decorators and hide them from the test list in VS. In general, we prefer to use the standard approaches to these things and keep them visible outside of VS; an annotation in the test file is preferable to a
separate "playlist" that only works in VS. For example, if third-party code doesn't follow the unittest naming conventions, people on your team who aren't using VS will face the same issue. A wrapper class like I mentioned above will also help them,
while a VS-specific setting won't.