Danek Duvall wrote: > [snip] >>> client.py: >>> >>> - what about adding and removing mirrors? I see the test code for this, >>> but those calls don't seem to be wrapped here. >>> >>> >> That's an interesting point. I'm definitely testing adding the mirrors, but >> I think it's possible it never reaches the mirroring code. The added tests >> do pass, but I'll wrap the calls here anyway in case we change the ordering >> in the future. >> > > I don't follow. How can you definitely be testing adding mirrors without > ever reaching the mirroring code? > > Ok, let me try to explain. I'm testing adding mirrors from the point of view that I run the pkg command with the appropriate CLI options to add a mirror. From that perspective I'm testing adding mirrors. Now, the way the code is implemented, before it ever tries to add or remove a mirror, it makes a call to image.set_authority. This call currently dies because of a permissions error. So, there's currently no way (that I've thought of) to actually touch the image.add_mirror in a way that will make it fail with a permissions error. >>> t_pkg_authority.py: >>> >>> - line 174: since you already have mtest as the primary authority, can't >>> you just remove test1 to test this? >>> >>> >> Sorry, totally lost on this one. Did you maybe mean a different line >> number? >> > > You create the image with the authority name "mtest" (line 166/167). Then > you add a second authority called "test1" on line 169. Then you add a > third authority called "test2" on line 174. It appears that what you're > testing is the ability to unset an authority, but I can't figure out why > you're creating "test2". You can already remove "test1" because it's not > the primary authority "mtest" is, so you don't need to create "test2" as > primary just to remove "test1". > > Note that test2 doesn't actually get created. It's called with the su_wrap so that it should fail. It's testing that adding the preferred flag doesn't cause a traceback (or a success somehow) when run with insufficient permissions. >>> - line 180: shouldn't "test.com" be part of bogus_url? >>> >>> >> Actually, it shouldn't be there at all. >> Pulled >> > > There are a handful of others in other tests, too -- might as well clean > them all up? > Sure, I'll pull them out in general. Brock > Danek >
_______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
