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

Rewrite tests in Go #127

Closed
AkihiroSuda opened this issue Jul 27, 2021 · 3 comments
Closed

Rewrite tests in Go #127

AkihiroSuda opened this issue Jul 27, 2021 · 3 comments
Labels
area/test Tests and CI kind/refactoring Refactoring

Comments

@AkihiroSuda
Copy link
Member

The current test suite is written in bash and perl, but we should rewrite tests in Go

@AkihiroSuda AkihiroSuda added area/test Tests and CI kind/refactoring Refactoring labels Jul 27, 2021
@balajiv113
Copy link
Member

Am looking into taking this up. To support tests for both vz and qemu drivers and also try to make it more stable (tests passing in first run and not via retries). Also github actions now supports macos-13 runner in beta.

Is there any specific approach we need to take here ??
The plan i was thinking is to have it more of a integration tests. Tests run on top of limactl built binary.

@jandubois
Copy link
Member

FWIW, I agree with rewriting the Perl bits, but I don't think Go is an appropriate language for integration tests (obviously it is the correct choice for unit tests).

I think using a framework like BATS (combined with jq) lets you write integration tests that are much easier to maintain and debug.

Having said that, whoever is going to spend the time on implementing this should have the final word on how it is done. 😄

@jandubois
Copy link
Member

As an example of using BATS, creds.bats is a Rancher Desktop integration test that makes sure you can access a registry.

It uses some helper scripts, so it runs on macOS, Linux, and Windows (in WSL) and can test both moby and containerd configurations (and on Windows can test both Linux and Windows binaries to talk to moby/containerd).

I very much like the brevity and simplicity of the test code, making it easy to write and change the tests once you understand how the helper functions make it work in the different environments. E.g. ctrctl is running either docker or nerdctl depending on which container engine has been configured.

@AkihiroSuda AkihiroSuda closed this as not planned Won't fix, can't repro, duplicate, stale Sep 19, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/test Tests and CI kind/refactoring Refactoring
Projects
None yet
Development

No branches or pull requests

3 participants