All the tests so far see a slice. The integration test sends individual requests and reads HTML as text, the component test renders a component without a browser. No test has yet seen whether a visitor with a real browser gets from choosing the day to the confirmation. That is the Kladde’s most important path, and in this lesson you write an end-to-end test for it: a program steers Chromium, fills in fields, clicks and reads what is on the screen. Once with JavaScript and once without.

What only a browser sees

The booking from lesson 2.5.6 consists of four requests: a form with GET for the day, a link for the time, a form with POST for name and address, and then a redirect to the confirmation. In between, quite a lot happens in the browser that no other test sees:

  • The browser assembles the requests. It reads name and value of the fields, appends the day to the address with the GET, sends along with the POST the antiforgery token that EditForm wrote into the page, and follows the redirect.
  • With JavaScript it is a different path. The script blazor.web.js intercepts clicks on links, fetches the new page with fetch and swaps only the changed part. Microsoft calls that enhanced navigation. For forms it applies only with Enhance; so even with the script, the browser submits the booking’s forms in the completely ordinary way.
  • Without JavaScript everything must work from HTML alone. The house rules demand that for every page. Whether that is true, only a browser sees in which the script is really off.

An integration test could rebuild the requests: read the token from the HTML, assemble the fields itself, check the redirect. But then it checks what you believe the browser sends. The end-to-end test lets the browser do that itself.

It costs more for that: seconds instead of tenths of a second, an installed browser, and when it turns red, the message often says only that an element didn’t appear. That’s why the Kladde has only one end-to-end test, for the public booking, and runs it twice.