On Wed, Jun 11, 2014 at 05:41:11PM +0200, Michal Privoznik wrote: > On 11.06.2014 11:19, Michal Privoznik wrote: > >> <snip/> > >>Seems we should be able to set up a dummy /sys/class/net environment in > >>order to test the new API's... Something I attempted with my recently > >>posted scsi_host changes. > > > >Yeah, unit testing is certainly in place. But honestly, I thought it > >would blow the size of this patches up. Again, something that a follow > >up patch will do. > > > > So, now that I'm thinking about how to implement this I see two possible > ways which I'm unable to choose between: > > 1) mock higher level functions like virNetDevSysfsFile() or > virNetDevSetupControl(). So if a function wants to reach say > "/sys/class/net/eth0/operstate" we can direct it into > "tests/virnetdevdata/class/net/eth0/operstate" > Pros: > - small set of high level functions, so the code should be rather small. > - we can keep whole sysfs dir struct in git > > Cons: > - Unable to simulate some corner cases (e.g. EINVAL on read()). > - keeping whole sysfs dir struct in git > > 2) mock lowlevel functions, like open(), ioctl(), etc. There's plenty of > functions in virnetdev.c that use lowlevel functions like socket(), ioctl() > to get data. > > Pros: > - we can model kernel behavior more closely (e.g. even run time setting of > some values like MAC/IP addressese, link state, you name it) > - clean git > > Cons: > - much more code > > I'm not hesitant to write the code, but I'd rather have an agreement on the > design before that. To me the answer depends on what you're trying to test. If you're trying to test that functions in virnetdev.c do the right thing with syscalls/files they use, then mocking the lowlevel is best. If you're trying to test code that merely uses functions in virnetdev.c then it is valid to mock the virnetdev functions themselves. If you're trying to do both, then mocking the lowlevel functions will cope with both. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list