On 02/10/2014 01:29 PM, Vincent Ladeuil wrote:
> A newcomer should not have to learn a different command for every
> component of the project, plus one for the integration tests, plus
> several others for tests that doesn't fit in these categories.
Is it that odd? Django guys run things one way, standard python guys
another. I think its odd we are trying to create a standard:
> I'd rather
> maintain a single place to define, select and run tests for the whole
> project than having to maintain a different code base for each
> component.
I don't agree this problem is as bad as you say it is. As a python and
django developer I expect a couple of things:
1) i can run tests via ./setup.py test
2a) I can test python code with: python -m unittest <discover|<path>>
2b) I can test python-django with ./manage.py test
We currently support all of this. In addition we have a handy script,
tarmac.sh which can run all unit tests as well as tests/run.py which can
run all integration tests if you have a cloud.
On 02/10/2014 01:29 PM, Vincent Ladeuil wrote:
> A newcomer should not have to learn a different command for every
> component of the project, plus one for the integration tests, plus
> several others for tests that doesn't fit in these categories.
Is it that odd? Django guys run things one way, standard python guys
another. I think its odd we are trying to create a standard:
https:/ /xkcd.com/ 927/
> I'd rather
> maintain a single place to define, select and run tests for the whole
> project than having to maintain a different code base for each
> component.
I don't agree this problem is as bad as you say it is. As a python and
django developer I expect a couple of things:
1) i can run tests via ./setup.py test
2a) I can test python code with: python -m unittest <discover|<path>>
2b) I can test python-django with ./manage.py test
We currently support all of this. In addition we have a handy script,
tarmac.sh which can run all unit tests as well as tests/run.py which can
run all integration tests if you have a cloud.