Test Architects Talk pt. 2 | Playwright vs Selenium

Summary

En este debate, los expertos comparan Playwright y Selenium, dos herramientas de automatización de pruebas de interfaz de usuario. Selenium, con una comunidad sólida y documentación extensa, enfrenta a Playwright, una herramienta de Microsoft que ofrece características frescas y avanzadas como el patrón de Pantalla, la simulación y las pruebas de componentes. Se discuten las ventajas de ambas y la importancia de elegir la herramienta adecuada según los requisitos del proyecto, destacando la flexibilidad y la educación continua en el campo de la automatización de pruebas.

Takeaways

• 🤖 Selenium y Playwright son herramientas de automatización de pruebas de interfaz de usuario (UI), pero Playwright está ganando terreno en el mercado.
• 🔝 Selenium ha sido la herramienta más popular por algunos años y cuenta con un poderoso soporte de la comunidad.
• 🌱 Playwright, desarrollado por Microsoft, ofrece características frescas y modernas que atraen a los usuarios.
• 🛠️ La decisión de implementar nuevas herramientas en un proyecto debe ser justificada económicamente y considerando la compatibilidad con las pruebas existentes.
• 📚 Existe una gran cantidad de material de aprendizaje para Selenium, pero Playwright también está ganando popularidad y recursos educativos.
• 🚀 Playwright ofrece ventajas como un umbral de entrada bajo para nuevos usuarios, especialmente en TypeScript, y una escritura de código más ordenada incluso por parte de desarrolladores junior.
• 🧩 Playwright apoya la prueba de componentes, invitando a los desarrolladores front-end a automatizar pruebas de comportamiento de la interfaz.
• 🎭 Playwright también ofrece la capacidad de hacer mock de solicitudes HTTP o módulos, y pruebas en aislamiento, lo que es apreciado por los testers.
• 📈 El soporte para tecnologías como Shadow DOM y componentes de React está más avanzado en Playwright, especialmente en su versión de TypeScript.
• 🌐 Playwright está desarrollado en TypeScript, lo que refleja una mayor madurez y funcionalidades en esta versión en comparación con Java, C# y Python.
• 🔧 La elección de la herramienta y el lenguaje de programación debe basarse en los requisitos del proyecto y no en la familiaridad o preferencia personal.
• 👨‍🏫 Se enfatiza la importancia de que los desarrolladores junior aprendan fundamentos sólidos de programación antes de especializarse en una herramienta específica.

Q & A

¿Cuáles son Playwright y Selenium y para qué se utilizan?

Playwright y Selenium son herramientas de automatización de pruebas de interfaz de usuario (UI). Selenium ha sido la herramienta más popular por algunos años, mientras que Playwright es una herramienta más reciente desarrollada por Microsoft que ofrece nuevas funcionalidades al mercado.

¿Por qué un programador junior podría elegir Selenium para sus proyectos?

Un programador junior podría elegir Selenium debido a su comunidad poderosa y la disponibilidad de soluciones y materiales de entrenamiento en línea, lo que hace que los problemas comunes ya hayan sido resueltos.

¿Qué ventaja ofrece Playwright en el mercado de las pruebas de UI?

Playwright ofrece un enfoque fresco al mercado, con características como soporte para Shadow DOM, un umbral de entrada bajo para nuevos usuarios en TypeScript, y la capacidad de realizar pruebas de componentes y de aislamiento, además de la implementación del patrón de Pantalla de Juego.

¿Cuál es la importancia de la comunidad en torno a una herramienta como Selenium?

La comunidad es crucial ya que proporciona soporte, documentación y soluciones probadas para problemas comunes, lo que facilita la implementación y resolución de problemas para los usuarios de la herramienta.

¿Por qué podría no tener sentido crear una herramienta únicamente para reemplazar a Selenium?

Crear una herramienta solo para reemplazar a Selenium no tiene sentido económico ni desde el punto de vista de la implementación, ya que Selenium está bien establecido, tiene una comunidad sólida y está en constante evolución, lo que significa que problemas anteriores han sido resueltos y se liberan nuevas versiones con nuevas funcionalidades.

¿Cómo es la experiencia de usar Playwright en diferentes lenguajes de programación?

Playwright fue desarrollado en TypeScript, lo que significa que la versión de TypeScript es la más completa y con más funcionalidades. La versión de C# también está bien desarrollada debido a la afinidad con Microsoft. Sin embargo, la versión de Java puede requerir más esfuerzo para implementar algunas características, como el soporte para Shadow DOM y las pruebas de componentes.

¿Qué es el patrón de Pantalla de Juego y cómo se relaciona con Playwright?

El patrón de Pantalla de Juego es un patrón de diseño antiguo que Playwright ya soporta. Este patrón ofrece una estructura para organizar y simplificar el código de prueba, lo que puede mejorar la legibilidad y mantenibilidad.

¿Qué se entiende por 'pruebas de componentes' y cómo Playwright las soporta?

Las 'pruebas de componentes' se refieren a la prueba de elementos individuales de la interfaz de usuario, como botones o etiquetas. Playwright ofrece soporte experimental para estas pruebas, lo que permite a los desarrolladores front-end automatizar y verificar el comportamiento de estos componentes.

¿Por qué es importante la capacidad de aislamiento en las pruebas de UI?

La capacidad de aislamiento es importante para asegurar que las pruebas se ejecutan de manera independiente y no se ven afectadas por el estado de otros componentes o pruebas. Esto ayuda a identificar de manera precisa los problemas y a evitar interdependencias en la suite de pruebas.

¿Qué es el patrón de 'auto-espera' y cómo ayuda en las pruebas de UI?

El patrón de 'auto-espera' se refiere a la capacidad de una herramienta para esperar automáticamente a que se carguen o se muestren los elementos de la interfaz de usuario antes de interactuar con ellos. Esto simplifica el código de las pruebas y reduce la necesidad de implementar explícitamente las esperas.

¿Qué sugerencias se dan para un programador junior que está comenzando con las pruebas de UI?

Se sugiere que un programador junior comience aprendiendo a programar en un lenguaje sólido como Java o C#, en lugar de enfocarse únicamente en una herramienta. También se aconseja ser tecnológicamente agnóstico y estar dispuesto a aprender nuevas tecnologías y conceptos.

¿Cómo se aborda la elección de la herramienta correcta para un proyecto en el script?

El script enfatiza la importancia de elegir la herramienta y el lenguaje de programación según los requisitos del proyecto, en lugar de intentar adaptar los requisitos a una herramienta específica. Se sugiere también tener en cuenta las habilidades del equipo y las disponibles en el mercado.

¿Por qué es beneficioso realizar un PoC (Proof of Concept) con una herramienta de pruebas?

Realizar un PoC es beneficioso ya que permite a los desarrolladores experimentar con una herramienta, evaluar su efectividad y aprender de su uso sin comprometer un proyecto grande o existente.

Outlines

00:00

🤖 Comparación entre Playwright y Selenium

Se aborda el tema de las herramientas de automatización de pruebas de interfaz de usuario, Playwright y Selenium. Selenium ha sido la herramienta más popular, pero Playwright, creado por Microsoft, está ganando terreno. Se destaca la importancia de la comunidad y la cantidad de material disponible para Selenium, así como las ventajas de Playwright como una herramienta fresca en el mercado. Se plantea la pregunta de si vale la pena crear nuevas herramientas y su implementación en proyectos, teniendo en cuenta que Selenium ya tiene una sólida base de problemas resueltos y una comunidad muy involucrada.

05:06

🛠️ Ventajas y características de Playwright

Se discuten las ventajas de Playwright, incluida su fácil entrada para nuevos usuarios en TypeScript, su capacidad para manejar elementos de espera en sitios web y su enfoque en el diseño de pruebas de componentes. Se mencionan características como la posibilidad de hacer mocking en diferentes niveles y la prueba en aislamiento, lo que demuestra la similitud de pensamiento entre los desarrolladores de Playwright y los testers. También se menciona el soporte experimental para pruebas de componentes y la implementación del patrón de pantalla de cine, que contrasta con el patrón de objeto de página conocido.

10:08

🔧 Desarrollo y soporte de Playwright en diferentes lenguajes

Se analiza el soporte y desarrollo de Playwright en lenguajes como TypeScript, C#, Java y Python. Se destaca que la versión de TypeScript es la más desarrollada y que, dado que Playwright fue desarrollado por Microsoft, es lógico que la versión de C# también esté bien desarrollada. Se menciona la importancia de la asincronía en .NET y la falta de soporte oficial para Async/Await en Java. Se discuten las ventajas de Playwright en términos de desarrollo y la rapidez con la que Microsoft aborda las propuestas y problemas en GitHub.

15:09

📚 Elección de herramientas y lenguajes de programación

Se debatir la elección de herramientas y lenguajes de programación para los recién llegados al campo de la automatización de pruebas. Se sugiere que el aprendizaje de programación es el primer paso y se recomienda aprender lenguajes como Java o C# antes de TypeScript o Python debido a las trampas para principiantes en estos últimos. Se enfatiza la importancia de ser tecnológicamente agnóstico y la capacidad de adaptarse a diferentes tecnologías y lenguajes, apuntando a la flexibilidad y el aprendizaje continuo en la carrera.

20:12

🚀 Conclusión y recomendaciones para proyectos y aprendizaje

Se ofrecen recomendaciones finales sobre la selección de herramientas para proyectos nuevos y existentes. Se alaba Playwright por su madurez y características, pero también se enfatiza la importancia de una elección de herramientas bien pensada basada en los requisitos del proyecto. Se anima a realizar pruebas de concepto (PoC) para aprender sobre nuevas herramientas y se sugiere que la elección final dependerá de múltiples factores, incluidos los tests existentes, el costo de mantenimiento y las habilidades del equipo.

Keywords

💡Playwright

Playwright es una herramienta de automatización de pruebas de interfaz de usuario (UI) desarrollada por Microsoft. En el video, se discute cómo Playwright está ganando terreno en el mercado, desafiando a Selenium, la herramienta predominante en la automatización de UI. Se menciona que Playwright ofrece características frescas y avanzadas, como la compatibilidad con tecnologías modernas y el soporte para pruebas de componentes, lo que lo convierte en una opción atractiva para nuevos proyectos.

💡Selenium

Selenium es una herramienta de automatización de UI muy popular que ha estado en el mercado por varios años. Aunque ha tenido sus altibajos, cuenta con una comunidad poderosa y una gran cantidad de material de entrenamiento en línea. En el video, se argumenta que, a pesar de los retos, Selenium sigue siendo una opción sólida debido a su amplio uso y la disponibilidad de soluciones conocidas y bibliotecas existentes.

💡Automatización de UI

La automatización de UI se refiere al proceso de realizar pruebas automáticas en la interfaz de usuario de una aplicación. Es el tema central del video, donde se comparan las capacidades y el uso de Playwright y Selenium para la automatización de UI. Se destaca que ambas herramientas están más allá de las pruebas UI tradicionales, abarcando también pruebas de API y componentes.

💡Comunidad

La comunidad se refiere al grupo de usuarios, desarrolladores y entusiastas que respaldan y contribuyen a una herramienta o tecnología. En el contexto del video, la comunidad de Selenium es mencionada como un factor clave detrás de su éxito y adopción, ya que proporciona una amplia base de conocimientos y soluciones para problemas comunes.

💡Migración de pruebas

La migración de pruebas implica el proceso de transferir pruebas de una herramienta a otra. En el video, se menciona la dificultad y la falta de sentido económico de migrar un gran número de pruebas de Selenium a Playwright, dado que Selenium está bien establecido y tiene una solución para la mayoría de los problemas encontrados.

💡Pruebas de componentes

Las pruebas de componentes son una forma de probar unidades individuales de la interfaz de usuario, como botones o etiquetas, aisladas del resto de la aplicación. En el video, Playwright se destaca por su soporte experimental para pruebas de componentes, lo que fomenta la automatización por parte de desarrolladores front-end.

💡Patrón de Pantalla

El patrón de Pantalla, también conocido como Page Object Pattern, es un enfoque para la estructuración de pruebas de UI que promueve la reutilización del código y la separación de la lógica de prueba de la estructura de la interfaz de usuario. Aunque no se menciona directamente en el video, se hace referencia a su desventaja comparada con el patrón de Secuencia de pantalla (Screenplay Pattern), que Playwright admite.

💡Secuencia de pantalla (Screenplay Pattern)

El patrón de Secuencia de pantalla es un enfoque más reciente para la escritura de pruebas de UI que se centra en el comportamiento de los usuarios en lugar de en la estructura de la página. En el video, se alaba a Playwright por admitir este patrón, lo que sugiere una mejor práctica y una aproximación más moderna a la automatización de pruebas.

💡Simulación (Mocking)

La simulación (o mocking) es la práctica de reemplazar componentes o servicios en una aplicación durante las pruebas para aislar el código que se está probando. En el video, se menciona que Playwright ofrece capacidades avanzadas de mocking, lo que permite a los desarrolladores probar componentes de forma más aislada y controlada.

💡Isolación de pruebas

La izolación de pruebas se refiere a la práctica de ejecutar pruebas de manera aislada para evitar interdependencias y errores en las pruebas. En el video, se destaca cómo Playwright admite la izolación de pruebas, lo que es una ventaja para aquellos que buscan una herramienta que permita un enfoque más controlado en la automatización de pruebas.

💡Programación

La programación es el proceso de escribir código para crear software. En el video, se discute la importancia de aprender a programar antes de enfocarse en una herramienta específica como Playwright o Selenium. Se argumenta que tener una base sólida en programación es fundamental para el éxito a largo plazo en el campo de la automatización de pruebas.

💡Agnóstico tecnológico

El agnosticismo tecnológico se refiere a la capacidad de un profesional para trabajar con diferentes tecnologías y lenguajes de programación sin prejuicios. En el video, se anima a los espectadores a ser tecnológicamente agnósticos, lo que les permitiría adaptarse y aprender nuevas herramientas y lenguajes según sea necesario para sus proyectos.

Highlights

Selenium y Playwright son herramientas de automatización de pruebas de interfaz de usuario (UI), con Selenium siendo la más popular.

La comunidad de Selenium es un factor clave tras su implementación, con una gran cantidad de problemas ya resueltos y documentación en línea.

Playwright, creado por Microsoft, está ganando terreno en el mercado como una herramienta de prueba de UI que aporta frescura.

El debate sobre la creación de nuevas herramientas para desafiar a Selenium y su justificación económica.

El soporte de Selenium para Shadow DOM y su evolución constante con nuevas versiones.

Playwright ofrece un umbral de entrada bajo para nuevos usuarios en TypeScript y mejora la calidad del código incluso de desarrolladores junior.

Playwright apoya la prueba de componentes, animando a los desarrolladores front-end a automatizar pruebas de comportamiento de la interfaz.

Playwright ofrece capacidades de simulación (mocking) a nivel HTTP y de módulo, y soporte para pruebas en aislamiento.

La implementación del patrón de Pantalla (screenplay pattern) en Playwright, que es una alternativa al patrón de objeto de página (Page Object Pattern).

Playwright está siendo implementado en nuevos proyectos por su madurez, características y velocidad en comparación con otras herramientas.

La documentación de Playwright es bien escrita, aunque Selenium tiene una documentación más extensa y mejorada con las versiones anteriores.

Las diferencias en la implementación de Playwright en Java, C#, y TypeScript, con TypeScript siendo la versión más desarrollada.

La versión de Playwright en C# es también muy desarrollada, posiblemente debido a que es un producto de Microsoft y beneficia de la asincronía de .NET.

La versión de Playwright en Java enfrenta desafíos con la asincronía y el soporte para Auto-Wait, a diferencia de TypeScript y .NET.

La importancia de ser tecnológicamente agnóstico y estar abierto a aprender nuevas lenguajes y tecnologías.

El proceso de selección de herramientas en proyectos debe basarse en los requisitos y no en la familiaridad con una herramienta específica.

La recomendación de aprender a programar primero y luego elegir una herramienta, destacando la importancia de las habilidades de programación sobre el uso de una herramienta específica.

La opinión de que Java es una buena opción para comenzar programando, seguida de TypeScript y C#, y la discusión sobre los desafíos de aprender lenguajes de scripting.

La experiencia de los participantes al cambiar de lenguajes y tecnologías en sus carreras y la flexibilidad requerida en el trabajo de pruebas de software.

El consejo de hacer pruebas de concepto (PoC) con herramientas新兴 para aprender y evaluarlas, incluso si no se utilizan en el trabajo actual.

Transcripts

Welcome back after the break with the second topic: Playwright vs. Selenium.

For those unfamiliar with these tools, Selenium and Playwright

are both UI test automation tools.

Although they're already starting to be not just for UI.

Selenium has been the most popular tool for a few years

and it has had its ups and downs.

What stands behind its implementation is that it has a powerful community.

A junior often chooses this tool because all the problems have already been solved.

The quality of these solutions is a different matter or the quality of the training that is available online.

When it comes to materials, there are indeed a lot of them. However, Playwright is spreading into the market.

It is an implementation created by Microsoft, a UI testing tool that brings a breath of fresh air to the market. I would like to ask the first question to Krzysiek.

Is there a point in creating new tools and implementing them in a project? I have a bit of a problem with any tool that wants to challenge Selenium.

First of all, when we hear or talk about any automation or UI automation, it is Selenium that we hear and think about.

A tool that would be created solely to replace Selenium, which is ingrained in so many projects and used so often,

this idea doesn't make any sense from the start. As you mentioned, all the problems with Selenium have already been solved.

There are libraries for it, solutions are known, available on the web and the tool itself is evolving,

newer and newer versions are being released.

We didn't have support for Shadow DOM before,

now Selenium already supports these things too. So the idea of creating a tool just to replace Selenium doesn't make any sense and economically is unjustified.

Imagine we have 300-400 tests and suddenly need to migrate them, it doesn't make sense.

It also depends a lot on the framework, because sometimes we have everything so wrapped up

that what goes underneath can also be easily replaced. It also depends on how we have the whole thing implemented.

It's good that you mentioned mature projects, but I know Daniel has been developing some new presentations recently and how does this new phase look now? I'll start by saying that I'm against GUI testing, but sometimes you have to do it, so in new projects, 2 years ago I was faced with a decision:

"Potentially, what could we take for end to end testing?". So not just for UI, but a tool that would make API tests.

I figured I hadn't researched the market for a long time and Cypress, and Playwright came through.

I did deeper research and at that point Playwright had reached the stage of outbidding Cypress in terms of maturity, features, speed.

Cypress had paid features at that point.

In general, there were things I didn't like.

As a Microsoft fanboy, of course - just kidding.

I've concluded that if Microsoft is developing it, it means something. Microsoft has been doing really good things in recent years. I made sure with a couple of friends that the Playwright actually delivers and we embraced it. The pros of Playwrights are that in typescript

this entry threshold for new people is quite low, it covers all the waiting elements of the site nicely and that code even written by a junior will be less sloppy,

but let's not put juniors to write a framework based on Playwright, because that code will be a bit better, but if someone can't code then that code won't be decent.

Also about the Playwright and speaking of components.

What I liked about Playwright is that it supports certain concepts that I like.

For example, component testing.

This is the concept of testing front-end components.

I can't remember exactly which technologies it supports, as this is experimental.

I like the concept itself because it invites front-end developers to automate.

That is, for the first time in a framework that is potentially for testers,

we have testing on the front end.

This component has three labels, 5 buttons and so on.

Let's check its behaviour.

This is what I call the 'interface behaviour test'.

And this is exactly what I encourage developers to do on the front end to write these tests.

That's what I liked about it, that they're trying to implement it, because it's not fully implemented, it's experimental.

A cool concept,is also the ability to mock, with Selenium or any other framework,

very much focus on the UI, and here we have the concept of mocking where you can mock something at the http or module level.

There are even two methods there, you can mock something at the browser level.

Another thing is something close to my heart, which is testing in isolation.

It's nice that the framework supports that.

Which tells me: These people think like me.

We think alike and that's why it became familiar to me.

What else made me think "they really have good ideas",

is the fact that they've implemented the not-so-popular screenplay pattern, which sees a lot of uncool things in the pattern that everyone knows, which is the Page Object Pattern.

So if anyone isn't familiar with the screenplay pattern, I recommend reading up on it.

This is a rather old pattern and Playwright already supports it.

So these few things have convinced me that Playwright is a cool tool and I'm implementing it into new projects.

At the moment we're implementing it in the script, and I know you guys are knowledgeable about how different languages are supported by Playwright.

More on the mocking, as we can also mock in the 4+ version.

Once you read the Playwright's documentation, you see it's very nicely written.

Selenium certainly has better documentation, from older versions.

But if we want to mockup something more complicated in Selenium, in different languages, there's an implementation in Java,

sometimes you struggle a bit to do the mockup, and in Playwright we have it very nicely and clearly written.

And there are of course differences between all of them.

There are quite a few differences in Java, C#, and TypeScript.

Not every implementation, e.g. component testing, is possible and I know that also Michał has a similar experience. Could you elaborate on this topic?

I also used Playwright in Java, C# and TypeScript. Playwright itself was developed in TypeScript, so you could say that most or all of the functionality is in that TypeScript version.

Also, TypeScript is a Microsoft product, so it's obvious that they're going to promote their technology as well, so TypeScript is the most developed with a lot of different capabilities.

Additional options such as, for example, a set of tests that we can divide into a group.

If we had several agents, e.g.

1/3 tests on one, on the second and on the third, i.e. such additional isolation is already available out of the box.

Of course, we could also handle this with some sort of tag, but here it's out of the box.

Shadow DOM support, react controls, experimental component testing support, or some additional traceviewer functionalities.

This tool is still in development and you can run tests from it.

All these features in other frameworks come later. After the TypeScript version, the C# version is the most developed.

This is a Microsoft product.

It's not likely to be a coincidence, but it's also an interesting reason, because I compared the number of commits in other versions, either C# or Java and Python.

You could say there's a gradation in that there's TypeScript and C# with the highest versions, then there's Python and Java. That's the reason why Playwright in C# is more developed than Java,

because it's asynchronicity, there is Async/Await available in .NET.

In Java, it's not officially supported.

I know that Electronic Arts has created their implementation of Async/Await in Java, but this is not yet officially supported.

The bigger problem in Java is what Daniel mentioned.

You mentioned this solution to the wait problem, auto wait, which for most situations works. Even if it doesn't work, what Playwright supports is the ability to wait for different types of requests, responses and certain content items.

In Java, I had to use these additional methods more often.

Now we'll do that in TypeScript and .NET, but would you use Playwright in Python or in Java for a new project?

I haven't used it in Python, but I would probably use it because I can see the development.

I followed the development a little, but I didn't use it.

In Java, yes.

In Java, I had this situation where I was starting from scratch.

I had the option to choose a tool and I chose Playwright.

As far as the development is concerned:

In Selenium, until recently, it was not possible to scroll a page by yourself at all.

You had to create an executor in order to scroll.

And so it went for a few years.

It wasn't until around June that a new version came out where we could actually do a scroll to an element via the Action class.

And that's the advantage of Playwright, that they actually don't have to ask sponsors for cash,

because Microsoft develops the whole thing and often, when someone sets up an issue on GitHub, it's actually resolved quite quickly and they implement new ideas.

This is actually great. 128 I also like that there is this educational element, because Selenium is already known to everyone. I find it very annoying in general how people get used to it.

It's just a tool.

It's about how and what we want to automate.

Very few people think about that.

And Selenium gives you a clear path.

That's cool that the tool is able to tell you

"Hey, here's a bookmark", you'll even notice it when reading the documentation.

There's a module for generating data too.

Or you want to see what mocking is.

Someone who has been writing Selenium all their life will see this and start reading about it and start educating themselves too.

So in my opinion Playwright is a good toll. I rarely comment on Microsoft tools in this way, but good job.

Maybe something will come out of it.

Some sort of tester who is both a frontrunner and a tester, because it blends so nicely.

Full stack tester. Yes, but here you have also addressed another issue. This tool selection process often looks bad in different organisations. We should be selecting the tool according to the requirements, not trying to fit the tool to those requirements.

Usually, we just want to use a particular tool and we try to fit it into all these requirements we have.

Because we only know this way.

We're getting biased.

A Junior, what should he use?

C#, Java, Python, TypeScript, Selenium, Playwright, what should he choose?

Because it's confusing.

That's a good question.

I think learnig how to program is the first step. You have to choose a language, whether it's C# or Java.

I personally would recommend Java or C#.

I think these are good programming languages to start with.

Typescript or Python can have beginner traps that can make things difficult, TypeScript and JavaScript even more so.

Because of the number of options there, we can also get lost while trying to write a good quality code.

When it comes to Playwright itself, that's a slightly more difficult question.

The TypeScript version itself is the most developed and stable, but there's also a problem with the programming language.

If we approach it in a way to develop this knowledge of programming in the script, we can make this choice, TypeScript and PlayWright.

If for some reason we choose C# or Java then we can go choose this way.

However, I wouldn't be afraid to change programming languages or technologies either.

You can't praise just one tool, you have to be open-minded.

We can always learn another programming language.

It's good to know one with solid foundations and then develop other skills.

I would also like to add, I agree with Michał, that we need to separate it well.

Does this person know how to use the tool, or can they program?

These are usually two different things, and in my experience, if a junior (no disrespect to juniors if they are listening to this debate) is very focused only on the tool and not learning how to program, then sooner or later that project will blow up or be expensive to maintain.

I would put someone on the project to oversee it.

But that's also generic advice, because mixing teams, less experienced people with more experienced people, helps those people through Code Review, et cetera.

We've also had that problem recently, I noticed generic errors during Code Review.

Sometimes I don't want to repeat the same thing over and over.

So I created a guidebook with rules, e.g. read up on solid, drive, how class hierarchies should be built.

If I see something like this in the code it's definitely wrong, so maybe that's a solution, but junior left alone is never a good option.

Marek wanted to say something.

I wanted to add to what you already mentioned, Junior is focusing too much on the tool.

He shouldn't focus on the tool and choose e.g. Playwright because it is the best in TypeScript,

and then just learn TypeScipt, the base knowledge. You have to start with a programming language and only then build the rest.

And in terms of programming language, I think Java is the best to start with.

I know you'll disagree. But all scripting languages later on are more challenging.

As testers, we're a bit on our own when it comes to DevOps.

After that, any integration with Jenkins, building docker images or not having full access to artifactory docker images, is so problematic that we end up with three versions of Python on the machine, no libraries and trying to pick up anything.

It's the same with TypeScript or JavaScript.

Actually, with Java I would disagree, because Java was probably one of the last languages I looked into.

But, I can see your reasoning.

There is some risk when starting with Python or TypeScript,

they're the ones that don't encourage object-oriented design though, it's not their DNA.

And C# or Java, they're harder.

We need to write more of this code, but it's a bit of a chore.

Learn this object-oriented programming that has classes, inheritance, compositions. That's a thing, because I have seen people who

were only using Python. These people didn't get to the object-oriented implementation level, they wrote in script.

Does that make any sense?

You've inspired me a bit.

Additionally, what we forget is that Junior will most likely start with this programming language, but he will not end there.

I started with Java myself, then I used TypeScript for two and a half years on a project, and at the moment I'm working with Python, so we have to remember that it's a tool too

and we don't need to be as polarising as iOS and Android.

It's good not to polarise, just to be open.

We can always learn something.

I often talk with candidates during interviews.

I ask: How many things we can use in addition?

Is it a new technology or are we going to try some convergence?

There are a lot of topics that each of us can say we don't know anything about. That's the advantage of our job, because if someone works for 5 years as a .NET developer they won't go to Java.

And the cool thing about our job is that we'll do implementations in Selenium, Java, C#, TypeScript, Playwright, so you can easily jump between those technologies and change or find a project.

I also wanted to add that when I look at the job listings, there are more Java and Selenium listings for juniors. Playwright sometimes comes up, but then someone is demanding more.

Finally, I would like to give a piece of advice that I love to give.

It's good to strive to be kind of technologically agnostic.

At least that's what I've always aspired to be.

Because even if we don't like Java or Python, if we try to understand the concepts behind it, they just become interesting.

If we get to know these concepts, then later on we see these concepts in others as well.

It is then easier for us to jump from one language to another. Each language also has its pros and cons, it's fun to learn about them.

Then it enriches us, we develop.

In addition, problems from one technology or language can already be solved in the other one completely.

Then we can try to adapt these solutions, knowing them, using them.

We already have knowledge about it and we can try something new.

To conclude, what would you choose in your projects?

All my projects currently are Playwright.

Unless I'm joining a project and see that there are already around a thousand tests written in Selenium, then it's not worth the cost, right, but still, for me Playwright is better.

Let's add that nobody pays us to promote anything.

We don't have any contract with Microsoft, although we encourage you to learn more about this tool.

We encourage it, especially as it is hard to find a downside.

I did such a solid research to find bigger cons,

if we would compare it with other tools like Cypress or Selenium, and it's hard to find downsides.

Even more so as we talk about a new project where we have a greenfield and we can choose.

Obviously, if there is a situation where we already have a large number of tests,

I would count what the maintenance cost is, so it depends.

If it turns out that we have 300, 500, 1,000 tests, but they're of poor quality, they fail every now and then,

then it might be a good idea to do a PoC (Proof of Concept).

I encourage to do PoC in general, take some tool, try it out just for the sake of learning, even if at work you don't have the opportunity to do it.

Let's try it out.

Let's write some tests for some sample online shop.

You can set up an online shop, CMS or WordPress and try to write some tests and see how it goes.

The choice of technology has to be calculated and well-thought out because there are a lot of different aspects to take into account.

The best proof that Microsoft is not paying us to advertise Playwright will be that I, nevertheless, encourage you to define your requirements first and then choose your tool and language.

Take into account who you're going to be working with and what the skillset of the team is and possibly what skillset is available on the market.

I think it's good that you mentioned it at the end because we got caught up talking about technology. I don't want to advise to take Playwright for every project.

People who are just learning and only know Selenium or Playwright. People who have to click, type, check, or download something on a daily basis, also easily learn these tools because they do the same thing.

Paradoxically, if someone starts with Selenium, then it's easier for them to implement in Playwright afterwards, because there might have been more problems in Selenium.

He wrote a bit more code to make everything work smoothly.

This is a good point too, because now imagine someone starts with Playwright and they are thrown it onto some Selenium maintanance project.

Well I think he would have a problem.

Well, then give us a thumbs up.

Thank you.

Another short break and we'll see you soon.