JarrodCTaylor/vim-python-test-runner

Is .vim-django required?

Closed this issue · 3 comments

We are already using nose for tests and have a

NOSE_ARGS="--cover-package=app1,app2"

defined which should limit the apps I tests I believe. Are there any other reasons the .vim-django file is required?

I retract my statement about cover-package being what limits the test packages.

But I still am curious if the file is required. If you are using "django_nose.NoseTestSuiteRunner" this should limit the apps where tests are run. So maybe if you make django_nose a requirement this fill would be optional?

Here is the flow of the program I'm not sure how to achieve it without a config file of some type, but I am sure open for suggestions if I am overlooking something.

The highest level and most basic django test command offered is to run all the tests for a app with no environment specified. This is called from the test file, and what we want to be able to build is a string to execute on the command line with the form of python path/to/manage.py test app_name

I have a function that will walk up the path looking for a manage.py file until it finds one or runs out of dirs to go up in which case it returns an error so we have the manage.py portion accounted for. The test arg is stock so no worries there. The tricky part is the app name. I don't have a better way of getting that without having it specified in a config file and then matching what is listed there with what is on the path to determine what app we are asking to run tests in. No way to tell where the settings file is to look for apps, because that is not always going to be straight up the tree from the test file.

For more granular commands such as running tests on a specific class or method that information is extracted from the test file based on the cursor position. So the sticking point is what app are we asking to run tests for. If we can come up with an alternative way to derive that info then we could perhaps make the config file optional.

Closing for now. Feel free to reopen if a new way to determine the current app emerges.