Testing

01

There is nothing to mock, because there is nothing in the way

No repository to stub, no in-memory database to configure, no test double for your own model. A test is an ordinary function marked [Test]: it calls your real functions, against your real entities, with your real rules switched on — on its own private copy of the database, thrown away when it finishes.

1[TestFixture]
void TwoPeople() {
  new User { Email = "ada@ember.test", PasswordHash = Security.HashPassword("x"), DisplayName = "ada" };
  new User { Email = "bo@ember.test",  PasswordHash = Security.HashPassword("x"), DisplayName = "bo" };
}

2principal Ada => User.Single(u => u.Email == "ada@ember.test");
principal Bo  => User.Single(u => u.Email == "bo@ember.test");

[Test(TwoPeople)]
3void an_anonymous_visitor_is_sent_to_the_door() {
4  Ui.Visit("/");

  Assert.OnPage("/login");
  Assert.Visible("a small room for a small team");
}

[Test(TwoPeople)]
void the_door_offers_both_ways_in() {
  Ui.Visit("/login");

  Assert.Visible("Sign in");
  Assert.Visible("Create account");
}

[Test(TwoPeople)]
void a_signed_in_person_with_no_channels_is_told_how_to_make_one() {
  Ui.SignInAs(Ada);
  Ui.Visit("/");

  Assert.Visible("Pick a channel");
  Assert.Visible("none yet — make one below");
}

02

Every test gets its own database

A fixture seeds the starting data once; every test that names it forks its own private clone of that state. Two tests under one fixture never see each other's writes — in any order, at the same time. A suite where one test's leftovers change another's outcome is a suite that fails at random and then gets ignored.

$ osy test
Starting a local platform for this project…

  ✓ a_note_is_invisible_to_everyone_but_its_owner (908ms)
  ✓ an_owner_still_sees_her_own_note (967ms)
  ✓ a_note_planted_for_somebody_else_is_not_even_EXPRESSIBLE (967ms)
  ✓ an_ITEM_is_invisible_when_its_list_is (627ms)
  ✓ an_item_cannot_be_added_to_somebody_elses_list (1103ms)
  … 16 more

✓ 21 passed.
⚠ the app's test set CHANGED since the last run — 24 declared then, 21 now:
    gone: shot_recall_lists, shot_recall_note, shot_recall_notes
  A count that holds still over a set that moved reads as "still green" while
  coverage moves.

Screen

03

The rules are the one thing nobody else can test for you

A security rule that is too strict fails loudly the first time somebody uses the app. A rule that is too loose fails silently, forever. So a test declares a principal and runs as them — and the interesting half is not the refusal.

[Test(TwoPeople)]
1[runas(Bo)]
void a_note_is_invisible_to_everyone_but_its_owner() {
2  Assert.Null(Note.FirstOrDefault(n => n.Title == "Ana's private note"));
3  // …and not by title alone: a listing must not leak it either.
  Assert.Equal(1, Note.Where(n => n.Title != "").Take(50).ToList().Count);
}

04

The same test drives the screen

Ui.Visit opens a route, Ui.Click presses what a person would press, and the same Assert.* verbs ask the questions. It is one file and one language — the test that checks a security rule and the test that fills in a form are the same kind of thing.

void a_message_you_send_appears_in_the_transcript_it_arrived_on() {
  Guid id = Guid.Empty;
1  runas (Ada) { id = CreateChannel("design", "how things look").Id; }

2  Ui.SignInAs(Ada);
  Ui.Visit("/c/" + id);

  Assert.Visible("Nothing here yet.");

3  Ui.Fill("Message", "morning — pushing the new rail today");
  Ui.Click("Send");

  Assert.Visible("morning — pushing the new rail today");
  Assert.Visible("ada");
4  Assert.Hidden("Nothing here yet.");
}

05

…and a tier that can see pixels

Every assertion so far is about TEXT or STATE, and all of them pass on a screen that is visually broken. osy test --pixels runs the same file in a real browser, where four more questions become answerable — and the difference is not academic.

Here is a checkout page. A promo ribbon ships, positioned over the card. The test is three assertions long and it is the test you would have written.

void the_confirm_button_is_there_and_a_person_can_press_it() {
  Ui.Visit("/");

  Assert.Visible("Confirm");        // text: on the page
  Assert.Enabled("Confirm");        // state: not disabled
  Assert.Clickable("Confirm");      // geometry: a press actually reaches it
}

$ osy test
    │ Assert.Clickable(…) — NOT CHECKED: this run renders in happy-dom, which has no
      compositor — every box it reports is 0×0, so nothing here can judge what covers
      what. Run the same tests with `osy test --pixels` to check them in a real browser.
  ✓ the_confirm_button_is_there_and_a_person_can_press_it (1361ms)

✓ 1 passed.

$ osy test --pixels
  ✗ the_confirm_button_is_there_and_a_person_can_press_it (2089ms) — at line 7:3
    Assertion failed: Assert.Clickable(…) failed: a click at 'Confirm's own centre
    (640, 140) lands on <div> "half price today" instead — something is covering it.
    That is what a person pressing it would hit, so the control is on screen and
    unusable.

✗ 0 passed, 1 failed.
  📷 1 screenshot(s) — one per UI test, with that test's own data — in osy-shots/

And it is how an agent gets eyes. Every UI test under --pixels photographs its own page, with its own data, into osy-shots/ — and the run prints the absolute path. Something writing your code can then open the PNG and look at what it built, which is a different kind of evidence from a passing assertion: an assertion checks the thing you thought to check, and a picture shows the thing you did not.

  📷 3 screenshot(s) — one per UI test, with that test's own data — in
     /Users/you/projects/shop/osy-shots

06

Time, and the network

The two things a suite normally has to pretend about.

07

What happens when you change it