quickly needs tests

[Rick Spencer]

It's too easy to make modifications that break commands. We need unit testing for quickly itself.

[John C Barstow (jbowtie)]

I started to look at this.

quickly.tools calls exit(). So you can't write tests for quickly_name (for example...) because the tests never finish.

The individual commands seem to be scripts, so you can't import them without executing them! This makes testing hazardous at best.

The obvious thing to do here would be to encapsulate each command in a class, and to handle errors by throwing exceptions. That way you can at least get things into a test harness.

See django.core.management.base.BaseCommand for a much-easier-to-test example of defining custom commands in a testable manner. Even better, just copy the django-admin approach completely; it results in much more maintainable code. You can even steal their test harness.

[John C Barstow (jbowtie)]

For the record, I'm volunteering to do this work if the team thinks this is a good architectural approach.

[Loïc Minier (lool)]

I didnt contribute much to quickly overall, but what you recommend definitely sounds like the way to go!

[Michael Terry (mterry)]

I'm marking this done. I've been updating the test framework and adding a bunch of tests for individual commands. It's now at the state where I've got good coverage and I'm going to start looking at other things.