You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
Whilst Trippy has some good unit tests for the
packet
andtracer
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 networkRun 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 deviceThis 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 thedns
,backend
orfrontend
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 mockNetwork
This will allow testing the
Tracer
algorithm against a dummyNetwork
which takes aProbe
and returns aProbeResponse
. This abstracts away all network logic.4: Testing the
net
module with a mockSocket
Similar to the above except this tests the
channel
module with a dummySocket
to abstract away platform specific behaviour.Tasks:
tun
based simulation test (IPv4 only) #908The text was updated successfully, but these errors were encountered: