rescript-compiler VS Cypress

However, for application programming I would recommend first learning something like ReScript, which is a very simple language with a powerful type system and it runs in the browser (so you can easily use all the JavaScript libraries). If you later decide to learn Rust, you will be able to use many things you learned in ReScript as they are both based on ML.

I'm quite the fan of Rescript myself, even just introduced it at my work. JS friendly syntax and comes with auto currying and pattern matching

I don't think Rescript[0] in fact they are pushing active updates. I think they are trying to make a push into supporting the ocaml ecosystem as well, and not just be a compile to JS language

[0]: https://rescript-lang.org/

Probably every developer that comes to ReScript stumbles upon a dilemma about which module from the standard library they should use to work with JavaScript API.

I wasn't familiar with this before. Thanks for being it to my attention! https://rescript-lang.org/

I find ReScript (https://rescript-lang.org/) fundamentally better than TypeScript. It has easy FFI and a sound typesystem. With Rescript you wont have any runtime errors, like you can with typescript. But compared to vanilla javascript typescript is a big improvement.

5. Cypress - 42.8k stars

Cypress doesn't like tests that take too much time to run. If a test takes too much time, Cypress can throw one of the following errors (there are GitHub issues about that - first, second). I've mentioned some ways to deal with it in this post.

We really want Cypress to make esbuild the norm everywhere. Give your thumbs up to the open feature request https://github.com/cypress-io/cypress/issues/25533 .

/** * Wait for a bunch of requests to be settled before proceeding with the test. * * Alternatively, https://github.com/bahmutov/cypress-network-idle could be used * * This is a workaround for "element is 'detached' from the DOM" Cypress' error (see the issue * linked below). Since the UI gets re-rendered because of the requests, this utility ensures that * all the requests parallelly made by the UI are settled before proceeding with the test. Hence, it * ensure the UI won't re-render during the next interaction. * * What are the requests that must be awaited? By looking at the Cypress Test Runner, they are the * following, made parallelly or in a rapid series. * 1. export_metadata * 2. export_metadata * 3. export_metadata * 4. test_webhook_transform * 5. test_webhook_transform * 6. test_webhook_transform * 7. test_webhook_transform * At the moment of writing, I'm not sure the number of requests are fixed or not. If they are fixed, * using the cy.intercept `times` options would result in a more expressive and less convoluted code. * * To give you an overall idea, this is a timeline of the requests * * all requests start all requests end * | | | | * |--🚦🔴--1--2--3--4--5--6--7----------------------------1--2--3--4--5--6-7--🚦🟢--| * * * ATTENTION: Despite the defensive approach and the flakiness-removal purpose, this function could * introduced even more flakiness because of its empiric approach. In case of failures, it must be * carefully evaluated when/if keeping it or thinking about a better approach. * In general, this solution does not scale, it should not be spread among the tests. * * @see https://github.com/cypress-io/cypress/issues/7306 * @see https://glebbahmutov.com/blog/detached/ * @see https://github.com/bahmutov/cypress-network-idle */ import 'cypress-wait-until'; export function waitForPostCreationRequests() { let waitCompleted = false; cy.log('*--- All requests must be settled*'); const pendingRequests = new Map(); cy.intercept('POST', 'http://localhost:8080/v1/metadata', req => { if (waitCompleted) return; Cypress.log({ message: '*--- Request pending*' }); pendingRequests.set(req, true); req.continue(() => { Cypress.log({ message: '*--- Request settled*' }); pendingRequests.delete(req); }); }); Cypress.log({ message: '*--- Waiting for the first request to start*' }); // Check if at least one request has been caught. This check must protect from the following case // // check requests start test failure, the requests got the UI re-rendered // | | | // |--🚦🔴----⚠️---🚦🟢-------1-2-3-4-5-6-7-1----------💥 // // where checking that "there are no pending requests" falls in the false positive case where // there are no pending requests because no one started at all. // // The check runs every millisecond to be 100% sure that no request can escape (ex. because of a // super fast server). A false-negative case represented here // // requests start requests end check check test failure, no first request caught // | | | | | | | // |--🚦🔴--1-2-3-4-5-6-7-1-2-3-4-5-6-7--⚠️------------------⚠️------------------💥 cy.waitUntil(() => pendingRequests.size > 0, { timeout: 5000, // 5 seconds is the default Cypress wait for a request to start interval: 1, errorMsg: 'No first request caught', }); Cypress.log({ message: '*--- Waiting for all the requests to start*' }); // Let pass some time to collect all the requests. Otherwise, it could detect that the first // request complete and go on with the test, even if another one will be performed in a while. // // This fixed wait protects from the following timeline // // 1st request start first request end other requests start test failure, the requests got the UI re-rendered // | | | | // |--🚦🔴---1---------------------1----🚦🟢----------------2-3-4-5-6-7-1----------💥 // // Obviously, it is an empiric waiting, that also slows down the test. cy.wait(500); Cypress.log({ message: '*--- Waiting for all the requests to be settled*' }); cy.waitUntil(() => pendingRequests.size === 0, { timeout: 30000, // 30 seconds is the default Cypress wait for the request to complete errorMsg: 'Some requests are not settled yet', }).then(() => { waitCompleted = true; }); }

Cypress is much more recent than selenium (I first used this approach 12-13 years ago). It looks like the same sort of thing though. Anyone reading this thread: if you code for browsers but have never done any browser automation, go look at https://github.com/cypress-io/cypress .

You might have noticed the e2e folder. That's a fully-functioning setup of Cypress for doing integration-level or even full end-to-end tests.

There's also the concept of E2E testing, making sure that, above the level of unit tests, the disparate parts of the code work well together. I like cypress for E2E testing. You can set it up to run on local as a pre-push hook or set it up in CI so that it runs before deploy and catches any failures.

One of the great parts of learning Cypress is that it’s really readable. Without much experience, you should be able to go through Cypress tests and understand what the tests are testing for. To make them even more readable and to give us some extra commands, I like to add Cypress Testing Library: “Cypress Testing Library allows the use of dom-testing queries within Cypress end-to-end browser tests.”

Unit tests eller end to end test tex cypress

As probably all Cypress fans know already, Cypress 10 was shipped without the "run all tests" feature due to "technical limitations" (they are apparently working on a solution, and here is where you can read all about why they removed it, what are the technical limitations, and all the complaints about it too)