test framework could use more predefined functions

[chris3torek]

Some module tests work by injecting some packet(s) using a port-and-socket pair generated by gen_socket_and_port. See, e.g., bessctl/conf/testing/module_tests/nat.py or bessctl/conf/testing/module_tests/etherencap.py. As long as the code has the form:

sock.send(data)
return_data = sock.recv(2048)

or similar, we're fine. But suppose we want to specifically test, e.g., that a packet with some attributes gets routed to some particular output gate:

def get_pkts_for_ogate(module, ogate):
    info = bess.get_module_info(module)
    for gate in info.ogates:
        if gate.ogate == ogate:
            return gate.pkts
    return 0

sock.send(pkt)
assert get_pkts_for_ogate(module, 0) == 0
assert get_pkts_for_ogate(module, 1) == 1

Now there is a potential problem: the sock.send call in Python waits for the socket data to get to the kernel, but getting into the kernel does not mean that the data have even arrived at the receiving UnixSocketPort in bessd (much less been dispatched).

What's needed here is a way to wait for the UnixSocketPort module's igate packet count to go up. This means we need to sample it once before the sock.send, and in a loop afterward. This code should probably be in the test framework so that any test can use it easily.

While at it, the test framework probably should define a function similar to get_pkts_for_ogate above, but generalized to handle both input and output gates. Rather than getting just the packet count it should get the IGate or OGate data from <module, direction, gate_num>. Then get_pkts_for_ogate(module, 0) becomes get_gate_stats(module, 'ogate', 0).pkts. But that's less important than hiding the "sample the count, then inject packet(s), then wait for packet to get dispatched" test case.

(If there's a better way overall to do this, that would be even better)

[sangjinhan]

Once we have a wide range of such helper functions, it would be beneficial to switch to the Python unittest framework, rather than using our custom one. At the moment writing a module test is somewhat arcane and exotic.

[shinae-woo]

I am taking a look. Letting me know if you have any wishlist added to it.

[sangjinhan]

663 introduced mechanisms to reliably feed packets to modules and dispatch the results. Thank you all 👍