Hasura's Console E2E tests chronicles

I joined Hasura in May 2022, and one of my first tasks was to fix the E2E tests of the Hasura Console, main Hasura's front-end application. The main problems were: they were slow, and they were flaky. Then, by digging into the topic, there was more to say, more to decide, more to fix, and more to do. This presentation is about what we found out, the problems, the best practices, etc.

Hasura PR Review WG presentation

Testing Best Practices - ReactJs Milano 2022

Cosa succeede se i test che scriviamo nel nostro team/azienda non sono facilmente leggibili (o addirittura "decifrabili")? Succede che i test stessi, invece che garantire confidenza sul fatto che il codice e l'app funzionino, aggiungono carico cognitivo invece che toglierlo, non permettono di capire cosa il codice e l'app dovrebbero fare perché sono piú complessi del codice stesso che dovrebbero testare, non danno confidenza nel fare refactoring, sono obsoleti rispetto al codice che devono testare Senza parlare che quando falliscono, non permettono di identificare il problema alla base del fallimento - non permettono di capire se é il codice che non funziona o sono i test stessi che non funzionano, ci portano ad accettare i continui fallimenti Riasumendo, il costo di avere test (CI piú lente, sviluppo piú lento, librerie esterne da mantenere aggiornate) non é ripagato dal vantaggio di averli. Senza dimenticarsi che tutti i punti di cui sopra frustrano non poco il team Durante il talk condivideró con voi le best practice generiche che ho imparato nel tempo per evitare di incappare nei problemi sopracitati, applicabili ad ogni tipo di test (Unit test, Component test, Integration test, Story test, E2E test).

[BACKUP] How do I avoid the next developer reading my code swearing at me (ReactJSDay 2022 talk)

Reading, understanding, and refactoring a TypeScript+React application can be challenging, even if it's small. I will tell you my story of when I jumped on the codebase of a small product to implement some last-minute changes before going live. I had an overall idea of what the product does, and the external team that worked on it received comprehensive documentation of our coding patterns and thorough code reviews. Despite that, being effective since the first day was hard for me. Why? Because four of the most important details that make a codebase immediately readable were missing, which are: - TypeScript' Discriminated Unions instead of optional properties (helpful to describe the domain) - Straightforward JSX code (ease reading and jumping through the code) - Explicit State Machines (describe what the app does from an internal perspective) - Cypress integration tests (tell what the app does from an external perspective) Apart from a long series of best practices, the listed ones are the most used in WorkWave RouteManager, a 250k-LOC front-end application.

How do I avoid the next developer reading my code swearing at me (ReactJSDay 2022 talk)

Reading, understanding, and refactoring a TypeScript+React application can be challenging, even if it's small. I will tell you my story of when I jumped on the codebase of a small product to implement some last-minute changes before going live. I had an overall idea of what the product does, and the external team that worked on it received comprehensive documentation of our coding patterns and thorough code reviews. Despite that, being effective since the first day was hard for me. Why? Because four of the most important details that make a codebase immediately readable were missing, which are: - TypeScript' Discriminated Unions instead of optional properties (helpful to describe the domain) - Straightforward JSX code (ease reading and jumping through the code) - Explicit State Machines (describe what the app does from an internal perspective) - Cypress integration tests (tell what the app does from an external perspective) Apart from a long series of best practices, the listed ones are the most used in WorkWave RouteManager, a 250k-LOC front-end application.

Flowcharts Everywhere lightning talk

WMF - Cypress Talk (no green screen)

Conviene testare un progetto front-end? Come è possibile farlo impattando il meno possibile sulle necessità di time to market? Grazie a Cypress, strumento nato per offrire la migliore esperienza di sviluppo possibile, è possibile: - avere un flusso di sviluppo veloce grazie all'automatizzazione dei controlli manuali ripetitivi - essere protetti da regressioni causate da nuove funzionalità front-end o back-end - avere una documentazione visiva del progetto e rendere facile il passaggio di consegne

WMF - Cypress Talk

Conviene testare un progetto front-end? Come è possibile farlo impattando il meno possibile sulle necessità di time to market? Grazie a Cypress, strumento nato per offrire la migliore esperienza di sviluppo possibile, è possibile: - avere un flusso di sviluppo veloce grazie all'automatizzazione dei controlli manuali ripetitivi - essere protetti da regressioni causate da nuove funzionalità front-end o back-end - avere una documentazione visiva del progetto e rendere facile il passaggio di consegne

Front-end testing on steroids with Cypress - Conclusions

Concluding slides for my "Front-end testing on steroids with Cypress" course.

JavaScript Testing: a Practical Approach - Introduction

Introductory slides for my "Front-end testing on steroids with Cypress" course.

Front-end Testing on Steroids (Ticino Software Craft)

Di Cypress tutti ne parlano e tutti se ne innamorano non appena lo provano, ma perché è così famoso? Perché gli sviluppatori frontend ci si trovano benissimo? Lo scopriremo analizzando alcuni test E2E, alcuni test UI Integration test (senza back-end) , e alcuni test di componenti React.

Javascript Testing, a Practical Approach - Conclusions

Concluding slides for my "Javascript Testing, a Practical Approach" course.

Javascript Testing, a Practical Approach - Introduction

Introductory slides for my "Javascript Testing, a Practical Approach" course.

Keep calm and forget FOMO (green screen)

Nowadays, we are bombarded with new frameworks, new libraries, new patterns. How could you manage this swollen river of knowledge? Should you know a bit of everything or should you concentrate on just one thing? There is no right answer but I would like to tell you my journey with Cypress: the whys, the hows, the results, and the by-products. I dedicated one month only to Cypress, I experimented with new learning paths, I returned to public speaking... And I knew tons of people. I received a lot of feedback, I wrote a GitHub book and I taught some courses. It worked pretty well for me and it shaped a new way of learning from now on.

Breaking the fear of front-end testing (vertical)

Writing tests is like using GIT: in a moment you wonder how you could work before discovering it. But how widespread is the practice of writing tests between us JavaScript developers? Is the entrance wall really insurmountable? I am going to give you some ideas to overcome the initial resistance by making you understand how and what to test and what NOT to test.

Deepening a thing at a time

Nowadays, we are bombarded with new frameworks, new libraries, new patterns. How could you manage this swollen river of knowledge? Should you know a bit of everything or should you concentrate on just one thing? There is no right answer but I would like to tell you my journey with Cypress: the whys, the hows, the results, and the by-products. I dedicated one month only to Cypress, I experimented with new learning paths, I returned to public speaking... And I knew tons of people. I received a lot of feedback, I wrote a GitHub book and I taught some courses. It worked pretty well for me and it shaped a new way of learning from now on.

Front-end Testing on Steroids (V2)

Why testing a front-end application is so hard? What are the main challenges you need to face? Why do the tests fail without a clear reason? This talk is about good testing best practices and the tool that is become the de-facto standard of UI Testing: Cypress.

Breaking the fear of front-end testing - 20m

Writing tests is like using GIT: in a moment you wonder how you could work before discovering it. But how widespread is the practice of writing tests between us JavaScript developers? Is the entrance wall really insurmountable? I am going to give you some ideas to overcome the initial resistance by making you understand how and what to test and what NOT to test.

Breaking the fear of front-end testing

Writing tests is like using GIT: in a moment you wonder how you could work before discovering it. But how widespread is the practice of writing tests between us JavaScript developers? Is the entrance wall really insurmountable? I am going to give you some ideas to overcome the initial resistance by making you understand how and what to test and what NOT to test.

Mastering UI testing - Voxxed Days Ticino 2019

October 2019, Voxxed Days Ticino 2019 (https://voxxeddays.com/ticino/) --- Abstract: Have you ever wrote a successful UI test? How many times did you end up discarding a UI test because it's brittle and unmaintainable? And even if you don't write tests, tell me: do you click/type/click/click/setcookie/click/click while developing your UI? --- I'm going to explain you the most important best practices that allow you to master the UI tests hell, sleep at night (because you are sure your project works as expected), test the back-end responses too and completely revolutionize the way you develop your UI! --- I'm going to talk about - UI testing best practices - live demos with Cypress - improve your workflow using a UI test framework as your everyday working tool (so it's not only about testing)

ReactJSDay 2019 Testing Course

These are the reference slides with a small portion of the contents needed for the "React Testing 101: component, integration, and end-to-end testing" course for the ReactJSDay 2019 conference. You can find everything in the https://github.com/NoriSte/reactjsday-2019-testing-course repository

Mastering UI testing - Working Software

July 2019, first Working Software conference (https://www.agilemovement.it/workingsoftware) --- Title: Mastering UI testing --- Abstract: Writing UI tests for the web is hard, a lot of times the tests are brittle and unmaintainable. You must run them multiple times and, sometime, you need to exclude some of them from your pipeline. I'm going to explain to you the most important best practices that allow you to master the UI tests hell. I'm going to show you how much a tool like Cypress can help you writing and maintaining your UI tests.

UI testing best practices - FEVR

In June 2019 I had a talk for the FEVR community (http://www.fevr.it/eventi/2019/06/ui-testing-best-practices/). The talk aimed to share my own experience with UI testing 🤙

UI testing best practices - Milano FrontEnd

In April 2019 I had a talk for the Milano Frontend community (https://www.meetup.com/it-IT/milano-front-end/events/256620617/). The talk aimed to share my own experience with UI testing 🤙You can find the recording (in Italian) at https://www.facebook.com/milanofrontendmeetup/videos/2312725798938924/

E2E testing meetup for CaFE

In March 2019 I had a talk for the CaFE community in Como (https://www.meetup.com/it-IT/Como-and-Frontend-CaFE/events/259556783/). The talk aimed to introduce the attendees to the amazing world of browser automation, mostly for E2E testing but some showed examples were about web scraping too.

E2E testing talk for Grusp MI

In January 2019 I had a talk for the Grusp community in Milan (https://www.meetup.com/it-IT/MilanoPHP/events/256407565/). The talk aimed to introduce the attendees to the amazing world of browser automation, mostly for E2E testing but some showed examples were about web scraping too.

E2E testing workshop for FETI

In fall 2018 I had a workshop for the FETI (FrontEnders Ticino) community in Chiasso (https://www.meetup.com/it-IT/FrontEnders-Ticino/events/258183736/). The workshop aimed to introduce the attendees to the amazing world of browser automation, mostly for E2E testing but some exercises were about web scraping too.