On 1 December 2016 at 11:45, Pablo Neira Ayuso <pa...@netfilter.org> 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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to