Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Integration Testing #759

Open
2 tasks done
fujiapple852 opened this issue Nov 5, 2023 · 1 comment
Open
2 tasks done

Integration Testing #759

fujiapple852 opened this issue Nov 5, 2023 · 1 comment

Comments

@fujiapple852
Copy link
Owner

fujiapple852 commented Nov 5, 2023

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:

@fujiapple852
Copy link
Owner Author

fujiapple852 commented Nov 11, 2023

GitHub actions can be connected to Tailscale:

https://github.com/tailscale/github-action

This would allow a cross-platform solution for case 2 above, with a Linux based TUN device in a remote machine made available via Tailscale.

Edit: works on Linux only so defeats the purpose

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant