Adding observability traces to browser tests
Integrating OpenTelemetry-based observability traces into end-to-end browser tests—starting from test initiation through application execution—enables richer failure debugging by allowing engineers to replay and analyze the full request path, rather than relying solely on logs or isolated error signals.
Éléments favorables
Extrait original
What if you could add it to a component test or a browser test, right? Or a mobile test and you go all the way through. And then that creates some really interesting ways of creating.
Contexte
Yes, exactly that. Because observability allows you to create traces, right? And so if you go, "Here's my trace key, and I want you to use it all the way through," some of those things get picked up in how you develop and pass things through. So I've got a whole bunch of talks coming out towards the end of this year where I'm showcasing some of the work that I'm doing. And I think it's got some really important things. Because for years, a lot of people would just focus on reading logs. And you have to know what connection that has, right? But you could always then - when OpenTelemetry came out and people were building it, you could go, "Oh, I could see it go through here." But you never knew exactly how it started. You just saw the data coming into the system. Because then if you see a failure and you go, "Oh, I have this data. Let's see if I can replicate it, how it came in." And if you fill in the form with the same data and it worked that time, you go, "Oh, okay, maybe someone's doing it in a different way." And now you can try to figure out how that person was doing it rather than going, "I don't know how to start this. Let me figure it out." And then kind of spending time. So it's about trying to front load some of that information into your test and then following it all the way through.
L’heure de début provient de la transcription fournie. L’alignement avec la lecture est en attente de révision.
Ouvrir l’épisode et rechercher à 44:15.