> On 19.8.2015, at 23.32, Markus Stenberg <[email protected]> wrote: >> On 19.8.2015, at 23.26, Juliusz Chroboczek <[email protected]> >> wrote: >> If anybody knows how to write a test suite for a routing protocol, I'm >> interested. I imagine a set of scripts that set up some virtual machines >> and perform some tests, but I have trouble imagining how it could perform >> a test such as the one described above. > > You don’t really need bunch of VMs. In order of decreasing hackiness: > > [1] you need to only steal i/o (hello, LD_PRELOAD) and play with the black > box that talks network protocols. > [2] Or alternatively, do some root level raw packet i/o on the interface(s) > the daemon uses. > [3] Or provide a box (/VM) which pretends to be whatever else is on the > network and changing topology and whatever, which deals with the > device/daemon/… (of course, you’re screwed if the protocol requires L2 > events, but some boxes can simulate this too) > > It is not really rocket science (I used to do test automation software for a > living at some point), but very seldom really done comprehensively unless > there is serious industrial interest.
Note: I everything I talk about applies to testing ‘a protocol’, there isn’t really anything particular magic about testing a routing protocol. And in case this was not obvious from the context, you _do not_ typically use a full implementation as the reference to test against, but instead e.g. write the tests based on particular test cases that are obviously derived from the spec, and test each implementation against each of those individually. You may need subset of the implementation (or even full one) to really pretend to be one, but usually limiting complexity of tests (=> having small subset of full protocol used per test case) is sensible. Usually you need - way to reset implementation system under test (SUT) to a specific state (e.g. ‘reset’) - way to inspect SUT state which is not visible externally (in case of routing protocol, probably locally installed routes) - way to do the I/O with SUT (in case of a RP, probably a socket, wrapped in one of the few ways noted above) Standard disclaimer: It’s been years since I did any other tests than hnetd ones (or unit tests for my own hobby things) :) Cheers, -Markus _______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
