Integration Testing

[fujiapple852]

Whilst Trippy has some good unit tests for the packet and tracer modules, it has has a very weak integration testing story right now, with no automated integration tests running in CI. Therefore each release requires manual testing for all functions on all platforms which is time consuming an error prone.

The tracking issue outlines the various flavours of integration testing that could be added and run in CI.

1: Testing of the trip binary against a TUN device or a real network

Run real command like trip example.com -m json and validate the results. This covers everything e2e, except the Tui which may require another strategy to test.

2: Testing the tracing module against a TUN device

This is the most important case as it allows us to test the platform specific idiosyncrasies related to the use of things like raw socket without having to fake anything inside Trippy. Running this in CI would gives us the most confidence in all changes which impact the tracer. This does not cover the dns, backend or frontend modules.

This will require creating a TUN device which we can use to simulate a network that will receive packets from Trippy (ICMP, UDP & TCP) and respond with a variety of pre-canned responses to exercise all code paths.

3: Testing the Tracer with a mock Network

This will allow testing the Tracer algorithm against a dummy Network which takes a Probe and returns a ProbeResponse. This abstracts away all network logic.

4: Testing the net module with a mock Socket

Similar to the above except this tests the channel module with a dummy Socket to abstract away platform specific behaviour.

Tasks:

• [x] #908
• [x] #999