The `test` keyword - proposal

[eladb]

Community Note

Please vote by adding a 👍 reaction to the issue to help us prioritize.
If you are interested to work on this issue, please leave a comment.

Feature Spec

Before:

bring cloud;
let b = new cloud.Bucket();

new cloud.Function(inflight (_: str) => {
  assert(b.list().length == 0);
}) as "test:bucket starts empty";

new cloud.Function(inflight (_: str) => {
  assert(b.list().length == 0);
  b.put("file1.txt", "hello");
  assert(b.list().length == 1);
  assert(b.get("file1.txt") == "hello");
}) as "test:get after put";

After:

bring cloud;
let b = new cloud.Bucket();

test "bucket starts empty" {
  assert(b.list().length == 0);
}

test "get after put" {
  assert(b.list().length == 0);
  b.put("file1.txt", "hello");
  assert(b.list().length == 1);
  assert(b.get("file1.txt") == "hello");
}

I really don't like that it's basically breaking 1000 grammatical rules and would love
feedback, but I tried to design this "backwards" from what my ideal experience as a developer > would be and this is what I came up with.

I think experimenting with this in the short term is likely going to be a useful exercise.

Use Cases

Exploring language support for making tests first-class citizens.

Make tests really easy to write.

Implementation Notes

We should make a cloud.Test resource first and then have test sugar down to it.

Component

No response

[eladb]

@ekeren wfyt?

[ekeren]

TBH, I am not sure 🤷

I was writing the code to test story11 TaskList, there are many options to implement this, here is one:

resource Test {
  tasks: TaskList; 

  inflight before() {
    for id in this.tasks.list_task_ids() {
      this.tasks.remove_tasks(id);
    }
  }

  init(name: str, test: inflight (Test): void) {
    this.tasks = new TaskList();
    new cloud.Funciton({
      this.before();
      test(this);
    }) as "test:${name}";
  }
}

new Test("get and find task", inflight (t: Test) => {
  t.tasks.add_task("clean the dishes");
  let result = t.tasks.find_tasks_with("clean the dishes");
  assert(result.len == 1);
  assert("clean the dishes" == t.tasks.get_task(result.at(0)));
}) as "${Math.random()}";

new Test("get, remove and find task", inflight (t: Test) => {
  t.tasks.add_task("clean the dishes");
  t.tasks.add_task("buy dishwasher soap");
  t.tasks.remove_tasks(tasks.find_tasks_with("clean the").at(0));
  let result = t.tasks.find_tasks_with("clean the dish");
  assert(result.len == 0);
}) as "${Math.random()}";

off course, in this example we would eventually extract Test as a base class

I your example, I am not sure how we will recreate bucket for each test.

[Chriscbr]

What about (slight tweak)

bring cloud;
let b = new cloud.Bucket();

test("bucket starts empty", {
  assert(b.list().length == 0);
});

test("get after put", {
  assert(b.list().length == 0);
  b.put("file1.txt", "hello");
  assert(b.list().length == 1);
  assert(b.get("file1.txt") == "hello");
});

Too similar to jest?

[eladb]

This feels like a mix of both special sugar and some functional syntax.

I rather the syntax to either be fully special or fully "legal".

Ideally we can come up with a way for this not to be a special case.

For sample, I've been thinking a lot about how I love Switft's trailing closures and how they are a great tool for creating DSLs.

Maybe if we have trailing closures in wing, this can simply become:

new cloud.Test() as "foo" {
  // da test
}

[Chriscbr]

Or

new cloud.Function() as "test:foo" {
  // da test
}

[eladb]

Yeah cloud.Test is basically a cloud.Function with a test prefix in its identifier.

(That's unrelated to this proposal)

[staycoolcall911]

Not sure I see much value in a Test resource over a Function for now, but I might be missing something. I'm converting this issue into a discussion we can get back to later. We'll make an issue out of it once the requirements become more clear.