We are the Sled team 🛷

We're an infrastructure team developing tools for all the FEDs at Wix. Our main focus is sled, highly scalable, cloud based system to parallelize jest execution.

More about sled:

https://www.youtube.com/watch?v=hbz63Ve-eIY

Exercise

The goal of this exercise is to learn&apply concepts to solve a loosely defined task. In this task you'll integrate and extend a popular test runner in the javascript ecosystem: jest.

In this exercise you will build a little demo of a "mini sled". Just like the real sled, we'd like it to be built on top of jest test runner. You can learn on some of jest's architecture in this video, the gist of it is that jest is a modular system, each of it's parts can be replaced, example of such systems: resolver, transformer, runner, reporter, etc.

The end goal is to make jest tests execute on another computer instead of the computer that actually invokes jest (the computer that runs npm test).

In this repository, you can see a directory called some-project, this project have jest wired, and some tests can be executed on jest via npm test (which is actually just invoking the jest command).

To mimick another computer, one might use a docker container (or simply another process).

Part 1 - Execute spec files on another computer

Create the facilities necessary to execute the spec files (one.spec.js, two.spec.js, etc.) on another process than the jest process. One option is to have a running docker container that will mimick a different computer, or simple have another process instead, to which you will communicate via a REST/RPC API.

You should not pre-load the spec files on the "remote computer" (nor the "remote computer" should read the files directly (It's a different computer after all!)), we will test your solution on a different project than some-project with completely different spec files.

Key points of the required flow:

Developer executing jest by running npm test
jest process is executing with a modified (by you) runner
jest process sending the spec files to "remote machine" (either one by one, or all of them together (consider the trade offs)) using a REST/RPC/gRPC API.
"remote machine" executing jest on the "remote computer" and feeds it the spec files
"remote machine" sends back the results to the local jest process that displays the results.

important: you must modify / integrate with jest test runner, not to create your own script, notice the flow above.

Part 2 - Allow debugging spec files while they're being executed on another computer

Create the facilities necessary to debug the remotely executed spec file. Start by reading node's debugger documentation. For example, if the user (developer), wants to debug his spec file, the developer might execute:

DEBUG=true jest -f one.spec

After putting a debugger; statement at the place where she wants the debugger to stop. A javascript debugger would open and the developer would be able to step over/into the code in the spec file (in the example one.spec.js)

Please note: we don't want you to implement the UI of the debugger, use one of the existing clients.

Bonus: Make part 2 without exposing additional port(s) on the docker container, you can, however, create additional docker containers. This is to mimick that the "remote machine" and the "local machine" are both behind firewall(s), but still can access a 3rd machine, a "jump host".

How to open a remote chrome debugger

You can also piggy back on the chrome's debugger UI, the one you get when you open developer tools, this UI is just a html/javascript application. Google also have a deployed preview you can access on this URL:

https://chrome-devtools-frontend.appspot.com/serve_file/@65d20b8e6b1e34d2687f4367477b92e89867c6f5/inspector.html?ws=localhost:9222/devtools/page/48ADDF60F6F031835C7539B1CA6025AD&experiments=true&remoteFrontend=true

Notice the localhost:9222/devtools/page/48ADDF60F6F031835C7539B1CA6025AD part, it says the devtools application what debugger to connect to. You can connet to some other chrome browser, or node debugger.

Im the example below, we start a Chrome browser and telling it open the debug port (9222), then we open (in another browser) the URL of a chrome debugger UI with the correct paramters to connect to the browser's debugger. (the example uses curl, jq and sed, however you can just perform the steps manually by inspecting http://localhost:9222/json)

# Start chrome with remote debugger
/Applications/Google\ Chrome\ Canary.app/Contents/MacOS/Google\ Chrome\ Canary --remote-debugging-port=9222

# Grab the correct page identifier with some jq and sed magic and open the browser on the chrome's debugger UI
open https://chrome-devtools-frontend.appspot.com/serve_file/@65d20b8e6b1e34d2687f4367477b92e89867c6f5/inspector.html?`curl --silent localhost:9222/json | jq -r '.[] | select(.type=="page") | .webSocketDebuggerUrl' | sed -e "s/:\/\//=/g"`\&experiments=true\&remoteFrontend=true

Initial setup (Optional)

Install docker, follow the instructions here. To learn more about docker check out this video.
We've attached a Dockerfile, that is used to build a docker image from which you run a docker container that simulates the remote machine. At the moment it's a simple http server that returns Hello world when you issue a GET request to port 8080. You can and should change that application to complete the task.
To build and run the docker container, follow README.md in the remote-machine directory.

Tips

Take the time to get a little familiaraty with node.js, the npm package manager, promises and async / await
Create a simple nodejs app and test it with jest test runner
ndb is an improved debugging experience for Node.js
Don't start writing any code for the task before you've checked the linked resources, they're here to help you on your quest.

Before Submitting

Make sure to use clean code. (References: Clean Code: A Handbook of Agile Software Craftsmanship, Code Complete ). Make use of tools that will help you with standard formatting an linting.
You will be required to explain your implementation, make sure you understand all of your code.

Submitting your project

The final result is a code that consists of a "client" (a modified jest (or jest subsystem)) and a "server" ("remote machine").

After you've completed your tasks, and you are ready to submit it, do the following:

Create a private git repository (preferably on github.com)
Make sure all the code is committed and pushed
Make sure you added a markdown file (README.md) with instructions on how to run your project from scratch, that must include any operations that is required in order to run the project
Clone your repo and use your instructions to see it works as expected
Add yurynix user to the repo (Master permission)
Send us an email with your repo link

You may send questions to yurym of the domain wix.com.

Good luck,

The sledders.

yurynix/mini-sled-exercise