On Thu 31 Jan 2008 at 09:06PM, Danek Duvall wrote:
> Looks nice. A couple things that come to mind:
>
> - You don't seem to allow for tests whose expected failure can be
> suppressed. I know we don't want to do that much, but when we're
> coming up to a release, it'd be nice to have a "clean" run once we've
> suppressed all non-stopper bugs.
I'm not aware of a way to do that in python's unittest framework.
> - There's no check for expected output. We don't have a lot of places
> where that's incredibly useful, but you'd want that in "pkg search",
> and maybe some of the informational subcommands (info, list, status).
> It might also be useful to check to make sure that an expected
> exception occurred (rather than a different one, indicating a different
> bug). Looks like from your second example that you do at least collect
> the output, so it shouldn't be hard to finish the job.
Yeah, there's a good example of how to do that in another python test
harness, testoob, so I will probably add a test by regex.
> - There's no way to check to see that something happened correctly on the
> filesystem that can't be seen in return codes or a second command
> (like, say, creating a Full image makes a var/pkg directory rather than
> a .opensolaris.org directory). This would be useful both client and
> server side.
I don't really understand-- wouldn't we simply call os.whatever() from
the test case?
> - It might be useful to ensure that network operations are closed
> forcefully if they appear to be hung.
Ok. As far as I know, there is no timeout mechanism, another issue I
see with unittest. I'm not yet clear if I could add some of these
features with a subclass of unittest, and/or if the time investment
would be worth it...
-dp
--
Daniel Price - Solaris Kernel Engineering - [EMAIL PROTECTED] - blogs.sun.com/dp
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
