csweichel/ruruku repository overview

You and your team have a list of testcases you want to execute prior to a new release. Because things are moving quickly many of those tests aren't yet automated, so testing becomes a team effort. Ruruku helps coordinate this team effort by offering a single, low friction contact point where testers can sign up, claim test cases and provide feedback.

Ruruku offers a YAML-based testcase description that is meant to live next to your code. When the time has come to go through the tests, run ruruku session start --plan testcases.yaml to start a test session on your ruruku installation. You can also use ruruku start testcases.yaml to spawn a local webserver that allows others to participate in the test.

Beware: this is a side project and it's early days. Here be dragons.

⁠Getting started

Ruruku runs on OSX, Linux and Windows. You can either get going on your local machine, in a Gitpod or run this in a Docker container.

⁠On your local machine

To get started download ruruku⁠. You'll need a set of tests that you want to run through. You can either create one yourself (ruruku plan) or use an example⁠. Use ruruku start testplan.yaml to start the API serer and test session.

To share that session with others, Serveo⁠ comes in handy, which exposes local servers to the internet. This way you can run ruruku on your local machine and share it with others.

⁠Gitpod

Gitpod is an online IDE that offers instant workspaces in the cloud (full disclosure: this is what I work on during the day). It makes trying things like ruruku a breeze. Ruruku itself was/is developed exclusively in Gitpod - I never once had to clone the repo locally.

You can either open use our demo repository⁠ which also serves a good starter for your own projects, or jump right in with the development workspace⁠ of ruruku which runs a full build.

⁠Hosting ruruku (Docker/Kubernetes)

Ruruku has a central server which hosts the Web UI (for tests) provides a gRPC based API for the command-line tools. The ruruku server starts with ruruku serve. There also is a Docker image available for each release.

Note that the ruruku server needs a place where to store the data. By default that's in /var/ruruku. To run a Docker container that makes this data persistent, you can use a volume:

docker run -p 8080:8080 -p 1234:1234 -v /path/on/my/machine:/var/ruruku csweichel/ruruku:latest

⁠Securing your installation

By default Ruruku runs without any transport encryption/security. This way getting started is easy, but it's not exactly secure. Especially if you intent to expose your Ruruku installation to the internet, it's a good idea to use TLS for the gRPC API server, and HTTPS/TLS for the UI server.

To enable TLS for the API server and HTTPS for the UI server, add the following to your config

server:
    ui:
        port: 443
        https: enabled
        cert: ui.crt
        key: ui.key
    tls:
        enabled: true
        cert: server.crt
        key: server.key

and use the --tls flag to pass the certificate to the client (e.g. ruruku session --tls server.crt list).

Hint: to generate a pair of self-signed certificates run:

openssl req -new -newkey rsa:4096 -x509 -sha256 -days 365 -nodes -subj "/CN=*/" -out server.crt -keyout server.key

⁠Create a testsuite

To create your own testsuite run ruruku plan which will guide you through the process. If you want to a converter that takes an existing testcase description and produces a ruruku one, make sure to look at ruruku plan --help and ruruku plan add --help.

⁠Development

⁠FAQ

⁠What's with the name?

Ruruku is Maori and means to draw together with a cord, bind together, lash, coordinate. It is pronounced just the way it's written - checkout the Maori dictionary⁠ for an audio sample.

⁠Why are you building this?

1. I wanted a fun side project that integrates Go and React in a single project.
2. Gitpod allows for a new kind of tools which no longer require complex hosting so that they can be available on the Internet. Your workspace becomes your hosting platform. I wanted to explore this concept in a real-world use-case.
3. When testing Gitpod we still have a handful of manual testcases. I hope that ruruku will be handy for testing those.