On 1 December 2016 at 11:45, Pablo Neira Ayuso <pablo@xxxxxxxxxxxxx> wrote: > I mean, it would be good if you place as much common code as possible > in the runner script, so individual unit tests don't result in too > much copy and paste. > Ok, I understand. Actually, as you know I'm just experimenting with this. Anyway the problem I see is that we could end losing a lot of flexibility. The current py testsuite is only able to perform one kind of tests because of this approach. In the other hand, the shell testsuite is able to perform almost any kind of tests because it only executes arbitrary binaries. So perhaps we could take an intermediate approach: * scapy tests are executed by the shell testsuite runner (they are standalone scripts) * we develop a common lib of functions inside tests/shell/testcases/scapy/ (for example common.py) * then, each scapy test load that common lib which includes most of the factorised code Common functions would be something like this: * configure(): we do the scapy configuration, network config, or whatever * load_ruleset): we pass a nft ruleset (a string) and load it using nft -f * check_result(): we grep the ruleset counters, or whatever I'm thinking of some tests we could have using this approach: * atomic replacement of ruleset during a network transfer * conntrack modifications (using the conntrack-tools binaries) * packet mangling, NAT, etc In any case, I think we should retain the ability to load nft rules, send/recv scapy packets and check for nft counters at any time during the execution. -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
