On Oct 18, 7:24 am, Russell Keith-Magee <freakboy3...@gmail.com> wrote: > On Sun, Oct 18, 2009 at 6:14 PM, berto <roberto.c.agui...@gmail.com> wrote: > > > On Oct 17, 5:33 pm, Russell Keith-Magee <freakboy3...@gmail.com> > > wrote: > >> I'd like to fix this problem, but while this problem exists, adding a > >> continuous integration server that crashes every time the developer > >> makes a Syntax Error doesn't sound like an especially good idea. > > > That's an excellent point. My initial implementation did have the > > same problem, but I have since fixed it as well as runserver. The > > changes are posted on github: > > > - autoreload patch adds checking for modifications on files in an > > errored state > > http://github.com/rca/django/commit/ef96339f7e766700e8739a591b226b63b... > > > - runserver patch adds files that have errors to the autoreload code > > changed loop > > http://github.com/rca/django/commit/e1d0be02b001155a09b012f4867de1efd... > > > - updated version of runtester using the functionality above: > > http://github.com/rca/django/commit/043e9723ae8fdb98745c2390f3ff92649... > > - and a minor patch to it: > > http://github.com/rca/django/commit/c1d62dbb58b1113a864ed5b1d35dd0b60... > > That's great - but if you leave it on github, it's going to get forgotten. > > This issue is being tracked on ticket #9589. If you want to ensure > this contribution isn't forgotten, turn your github changeset into a > patch, and upload that patch to the ticket. You can also reference the > github changeset in the ticket comments, but not all the Django core > uses git. > > > But, just like the test command, the runtester command takes a list of > > apps, or even a TestCase class within an app. That way you are simply > > running a subset of the tests on the app actively being worked on. > > For example: > > > ./manage.py runtester some_app.SubTest > > > With the above command, only the SubTest tests are run, which will > > drastically reduce the time to run the tests. Granted time to setup > > and teardown of the test environment is still there. > > Well, sure, except for the fact that if you do this, you no longer > have continuous integration :-) The point of a test suite is that you > run *all* the tests, so that you can catch *all* the possible > regressions. Sure - if you're just doing a quick check of something, > you might just run a single test, but you need to run the full suite > to be sure.
Maybe I used the wrong name to describe the feature? I was basically looking for a way to run tests related to the work currently being done. I'm not suggesting that running the entire test suite is not necessary, surely it is. > That's why I suggest that CI is better suited as a checkin trigger. A > checkin is an indication that you think a body of work is complete. > Running the full test suite is then an appropriate validation step. A > single file save doesn't give you that sort of certainty that a body > of work is complete. I think we're in agreement here. > When it takes a while for a test suite to run (which will be true in > Django even if you're only running a small subset of the overall > suite), it could be easy for a test suite to start running on a > partially saved set of updates, which could result in confusion over > exactly which version of a which files were used to run a test. Sounds like you're interpreting what I'm looking as a feature, a bug. :) I want to write tests and see them fail continually until I have written the code that makes them pass. > kGiven the fact that it takes a long time to setup and teardown > Django's test suite, I feel that it is better to leave test execution > as a manually invoked process. That way the developer can be certain > of the exact file versions that will be used for a test run. Alright, well, thanks for your input. I'll use the test runner throughout the project I'm working on and see how useful it actually is! -berto. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
