On Sun, Dec 7, 2008 at 12:02 PM, Michael A. Smith <[EMAIL PROTECTED]> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Regarding gentoolkit/trunk/src/equery/tests > > I discovered all the test kit that's in equery, and have been refactoring > 'em. > They're written in bash, not python, so they're a candidate for some kind of > python unit testing. Right now, however, that's not a priority for me, so > I'm > just making the bash cleaner and hopefully faster and more maintainable. I > think it'll be helpful as we refactor. > > The question is, how maintainable are the "help" tests? These are tests that > try to confirm that the --help output of each module is correct. I think it > might be more work than it's worth to try to maintain those... > > Thoughts?
I know some people like to write the tests and then write the code to match, but I don't think it's a good idea for you to refactor the tests as I'm refactoring the codebase :) Especially since I'm chopping and moving things, renaming functions, etc, as long as I think it'll help in the long term. I even changed the format of the help output ;) Why? Because we have two user-oriented tools with a similar "modular" design, equery and eselect, and yet they have a totally different naming scheme and behave quite differently. It's unnecessarily confusing so I tried to make them more uniform (I'll upload some code shortly). I always though equery's --help was cluttered and confusing. A complete overview is what `man equery' is for, IMHO. I also changed the way equery handles input slightly. For example this I think is unnecessarily lenient and in the end confusing, because it goes against what most other tools do (raise an exception): $ equery -q -i list mozilla-firefox !!! unknown global option -i, reusing as local option So, I don't think we should be working on the tests until we have most of the code refactored, but I re-extend my invitation for help on that because there's quite a bit to do! -Doug
