Zen y el Arte de Pruebas de Componentes de UI

Rate this content
Bookmark

Sí, necesitamos probar nuestros componentes de UI pero... Si esto te suena, y especialmente si tu aplicación tiene funcionalidades de UI avanzadas, esta charla es para ti. En esta charla, cubriremos cuáles son los factores que necesitan ser probados en los componentes de UI. Desafiaremos la pirámide de pruebas cuando se trata de pruebas de componentes de UI, y revisaremos las diferentes herramientas que tenemos hoy en día para hacer que las pruebas de componentes de UI sean completas Zen.

21 min
11 Dec, 2023

AI Generated Video Summary

La charla discute la evolución de la automatización de pruebas desde la pirámide original de automatización de pruebas hasta la pirámide de pruebas. Explora enfoques modernos para las pruebas de componentes de UI, incluyendo aislamientos y pruebas con un DOM falso. Se destaca la importancia de las pruebas en un navegador real y la aparición de herramientas como Selenium, WebDriver.io, Puppeteer, Cypress, y PlayWrite para la automatización del navegador. Se explican las ventajas de la automatización del navegador fuera de proceso, junto con el uso de Storybook y Playwright para pruebas de componentes. También se menciona la distinción entre las pruebas de extremo a extremo y las pruebas de componentes.

1. Introducción a la Pirámide de Automatización de Pruebas

Short description:

En 1990, las pruebas no se enseñaban en las masterclass de programación. Un libro publicado por Mycom introdujo la pirámide original de automatización de pruebas con tres niveles: unidad, servicio y UI. Con el tiempo, evolucionó hacia la pirámide de pruebas, con pruebas de unidad, pruebas de integración y pruebas de extremo a extremo.

Un breve paseo por el camino de la memoria. Este soy yo. Aquí acabo de graduarme en mi masterclass de programación que fue en el Ejército Israelí, la masterclass de Mammran. Aprendimos muchas cosas. Lo único que no aprendimos es testing. Y esto es porque el año es 1990. Y este es el mismo año en que se publicó este libro por Mycom. Y está hablando de tener éxito con Agile. Y si te sumerges en este libro, encontrarías este diagrama. Este es el pirámide original de automation de pruebas. Habla de tres niveles. Unidad, servicio y UI. Y te das cuenta de que la UI está en la parte superior. Más tarde, esto evolucionó hacia la pirámide de testing, que todos conocemos. Y el nombre cambió. Todavía hablamos de prueba de unidad. Pero también hablamos de integración. Y la prueba de UI se ha convertido en prueba de extremo a extremo. Y esto es realmente cierto, porque esto es lo que sucedió durante muchos años. Veríamos la prueba de extremo a extremo como un sinónimo

2. Enfoques Modernos para la Prueba de Componentes de UI

Short description:

Quiero hablar sobre los enfoques modernos para la prueba de componentes de UI. El primer principio es el aislamiento. Los componentes te permiten dividir la UI en piezas independientes y reutilizables. Puedes pensar en cada pieza de forma aislada, construirla de forma aislada y probarla de forma aislada.

para pruebas de UI. Mi nombre es Tali Barak. Trabajo para una empresa llamada Ubiq. Y quiero hablar sobre enfoques modernos para la prueba de componentes de UI, y llamo a esta charla Zen y el Arte de la Prueba de Componentes de UI. Y pronto, veremos qué es el Zen y cómo podemos lograrlo.

Y lo primero, el primer principio, es que quiero hablar sobre aislamientos. Esta es una página, lo que una página web, una aplicación web parecía en los años 90. Como puedes ver, es bastante simple y es solo una página. Pero luego, más adelante, y estamos hablando aquí sobre 2015, más o menos empezamos a trabajar de una manera completamente diferente al construir nuestra aplicación web. Empezamos a hablar sobre componentes. Esto es AngularJS, como dije, en diciembre de 2015. Están hablando sobre entender los componentes cuando desarrollas una aplicación Angular. Y esto es de junio de 2016. Este es el commit real que se hizo en el readme de React. Y también empezó a hablar sobre lo que significa ser basado en componentes. Habla sobre la construcción de componentes encapsulados que gestionan su propio estado y luego los componen en UIs más complejas. Y todavía vemos a los componentes como una especie de ladrillos de lego. Tienes un componente separado de la exhibición. Cada uno con su propia funcionalidad y luego vas y los construyes en UIs más grandes como barcos, casas, o incluso un servidor de rack de motor de búsqueda que fue construido con lego.

Hoy cuando hablamos del marco moderno para construir UI como Angular, React, Vue, Solid, Svelte, etc., todos están construidos sobre el principio de basado en componentes. Y esto es lo que te permiten hacer los componentes. Te permiten dividir la UI en piezas independientes y reutilizables y puedes pensar en cada pieza de forma aislada. Y cuando dices pensar, no se trata solo de pensar, también se trata de construirlo de forma aislada y probarlo en aislamiento. En este ejemplo aquí, podemos ver que esta es una aplicación CodeWe, una aplicación de demostración que está construida en múltiples lenguajes y frameworks. Puedes encontrar casi cualquier framework que te gustaría. Y puedes ver aquí que en realidad está utilizando el mismo componente de una vista previa de artículo tanto en el feed global como en MyPost. Y esto implica que si quiero probar la funcionalidad de este componente, no necesito ir a la página específica del feed global como lo haría en la prueba de extremo a extremo o iniciar sesión e ir a MyPost como lo haría en la página de MyPost. En realidad puedo aislar este componente, ponerlo por separado. Y como vemos aquí, este es el mismo componente, pero la página solo muestra este componente. Esto está utilizando Storybook. Storybook es una gran herramienta para demostrar y mostrar y exhibir componentes en aislamiento.

3. Pruebas de Componentes de UI con un DOM Falso

Short description:

Puedo probar mi componente de forma aislada. Al probar componentes de UI, utilizamos herramientas como Jest o V-test, que trabajan con un DOM falso. Este DOM falso se crea utilizando motores como Node.js, pero no replica completamente el comportamiento del navegador. Por lo tanto, al probar componentes, se siente como jugar a adivinar, ya que no podemos ver el lado visual real. Nos apoyamos en herramientas como enzyme o testing library para ayudarnos.

Aquí puedo ver que esto es de la misma aplicación. Tomé el componente del editor. Esto es cuando quiero componer un artículo. Y puedes ver en el mismo Storybook, tengo este componente de forma aislada. Y una vez que tengo este componente, esto es acercándome al componente, realmente puedo probar que funciona correctamente, independientemente de en qué página se coloque. Así que puedo verificar aquí que tengo mis likes, que puedo hacer clic en ellos. Puedo verificar que el read es en realidad la referencia a la correcta URL. Puedo probar aquí que estoy mostrando las etiquetas correctas, que están en el orden correcto si hay una regla específica para el orden y así sucesivamente. Así que el punto número uno es que puedo probar mi componente en aislamiento. La otra cosa cuando hablo con la gente sobre los componentes de UI, ¿cómo los pruebas? Ellos generalmente dirían algo. Sí, quiero probar los data, quiero probar la interacción del usuario, quiero probar el diseño, quiero probar que genera eventos y usarían herramientas como Jest o V-test para probar mis componentes. Lo importante a entender cuando estamos usando Jest es que generalmente no estamos usando un navegador real sino lo que se llama un DOM simulado. El de arriba es muy popular. También hay uno más nuevo que se llama HappyDOM. ¿Qué significa trabajar con un DOM falso? Cuando estamos construyendo nuestra aplicación web, independientemente de si es un componente o no, bajo el capó, todavía necesita llamar al DOM, el modelo de objeto de documento, que es el núcleo de cómo funciona el navegador. Y cada vez que construimos un componente, y realmente no importa qué frameworks usemos, al final del día, necesitará llamar a las APIs del DOM para renderizar el componente. Podríamos envolverlo en algún JSX o TSX o plantillas de Angular o lo que sea, pero bajo el capó, todavía necesita ser traducido a selector de consulta, crear elemento, establecer atributo, agregar escuchador de eventos, y todas las API que conocemos en el DOM. Y generalmente estas API son proporcionadas por nuestro navegador. El navegador se ajusta al estándar de cómo funcionan las API del DOM y las usaríamos. Pero lo que la gente decide hacer con un DOM falso es en realidad tomar otros motores que pueden ejecutar JavaScript, y en su mayoría esto es Node.js. Nosotros tenemos algunos otros motores hoy en día, pero Node.js es definitivamente el más popular. Y construimos todas las API que el navegador tiene pero en Node.js. Pero lo importante a entender es que sí, falsificamos las API, pero realmente no hacemos lo que hace el navegador. Y esto significa principalmente que no estamos renderizando realmente el componente porque esto sigue siendo falso. No sabe cómo renderizar componentes. Y lo que la gente dice muy a menudo es que cuando estás testing tu componente de esta manera, se siente un poco como jugar a qué hay en la caja. Porque el componente, este es un componente de UI, tiene un lado visual, pero realmente no lo estamos viendo. Así que estamos intentando, cuando estamos testing, intentar adivinar qué hay dentro. Estamos usando herramientas como enzyme o testing library y así sucesivamente. Pero aún así, esto es mucho de juego de adivinanzas.

4. Pruebas de Componentes de UI y Automatización del Navegador

Short description:

Al trabajar con componentes de UI avanzados, puede ser un desafío simular APIs y crear un DOM falso que simule con precisión un navegador. Las pruebas en un navegador real son esenciales para garantizar una representación adecuada, funcionalidad CSS y pruebas de interacción. Con los años, han surgido varias herramientas para apoyar la automatización del navegador, incluyendo Selenium, WebDriver.io, Puppeteer, Cypress y PlayWrite. Las pruebas en un navegador real y la eficiencia son dos objetivos clave en las pruebas de componentes.

Y especialmente cuando estamos trabajando con componentes de UI advanced, componentes de UI que tienen cosas como medios advanced, que tienen lienzos y gráficos que se están animando. Y tenemos muchas microinteracciones y también tenemos muchos gestos que necesitamos soportar, como arrastrar y soltar o hacer zoom y así sucesivamente. Aquí es donde la simulación de las APIs se queda realmente corta. Y a veces es muy difícil y estás intentando hacer que tu DOM falso, navegador falso funcione como un navegador y inviertes mucho tiempo y es realmente frustrante en la prueba. Porque al final del día, es muy simple. Cuando tenemos componentes de UI, queremos probarlos en un navegador real. Y esto significa que realmente renderizará nuestro componente. No solo vamos a probar que tenemos la clase CSS correcta, sino que también queremos probar que el CSS está construyendo nuestro componente correctamente y que se visualiza correctamente. Queremos hablar sobre la llamada a la red que a veces es diferente cuando estamos trabajando con el navegador. Queremos probar la interacción, todos los gestos que mencioné, y también el tiempo adecuado. Cuando estamos trabajando con un mock, normalmente no se ajusta al tiempo que realmente tiene el navegador, o al evento pseudo y así sucesivamente. Si hay efectos secundarios, de nuevo, el evento pseudo es un ejemplo, como el cambio de entrada y así sucesivamente, queremos asegurarnos de que se dispara correctamente, y no nosotros disparándolo manualmente, y al final del día podríamos querer mirar realmente el componente y hacer una captura de pantalla y hacer una prueba de regresión visual y asegurarnos de que se vea exactamente como esperábamos que se viera. Y a lo largo de los años, hay muchas herramientas que apoyan este tipo de automation del navegador. Normalmente son sinónimo de pruebas de extremo a extremo, de nuevo desde este enfoque, se dice que la UI solo se prueba en pruebas de extremo a extremo. Tenemos Selenium desde hace 20 años, tenemos WebDriver.io que es muy popular. Estos no son los únicos. Y recientemente, en los últimos años, tenemos herramientas más modernas como Puppeteer y Cypress, y probablemente la última y mejor adición es PlayWrite junto con la versión más nueva de Selenium. Y discutiremos cómo son diferentes. Entonces, para lograr nuestro segundo punto final, queremos asegurarnos de que probamos en un navegador real. El tercer punto para hacer esta testing zen y divertida, queremos que sea eficiente. Queremos asegurarnos de que escribimos la prueba y que se ejecutan rápido y fácil de cambiar y fácil de hacer todas las cosas que necesitamos encima de ellas. Y para entender cómo podemos lograr la eficiencia, vamos a acercarnos un poco al navegador. Esto es lo que conocemos como el navegador, pero en realidad es el proceso de renderizado del navegador. Esto es lo que vemos en la pantalla. Tiene JavaScript, y ahora también tiene workers. Pero bajo el capó, el navegador tiene muchos otros procesos como los que ves aquí. Tenemos el proceso del service worker. Tenemos el proceso de red. Tenemos todos los procesos del navegador, cosas que controlan la security, la ubicación, las entradas, obteniendo la entrada del sistema operativo y enviándola al navegador, y muchas otras partes. La primera generación, o lo que era común para probar los procesos,

5. Automatización del Navegador Fuera de Proceso

Short description:

De esta manera, podrías ejecutar tu prueba en JavaScript, pero todo lo demás no estaba accesible para ti. La segunda generación son esos navegadores falsos de los que hablé, que todavía son populares. El enfoque más moderno es tener una automatización fuera de proceso. ¿Qué obtenemos con la automatización del navegador fuera de proceso? ¿Por qué es tan bueno? En primer lugar, tenemos acceso completo al sistema de archivos porque esto es externo y no se está ejecutando en el navegador. Multi-idioma, no tiene que ser JavaScript. Tenemos control total porque estamos accediendo a través de la API. No estamos limitados a solo una ventana o una pestaña donde se están ejecutando nuestras pruebas. Entonces, ¿qué significa eso para nuestras pruebas de componentes ZenUI? Esto es lo que estamos haciendo en ubiq. Estamos utilizando una combinación de Playwright y Storybook para probar nuestro componente.

era ejecutar realmente en el proceso JavaScript dentro del navegador. De esta manera, podrías ejecutar tu prueba en JavaScript, pero todo lo demás no estaba accesible para ti. No podrías hacer una entrada real, no podrías impactar la ubicación o la security, y así sucesivamente.

La segunda generación son esos navegadores falsos de los que hablé, que todavía son populares, que básicamente dicen que no tenemos nada de esto, solo estamos escribiendo en Node algunas de las pruebas que queremos. Y el enfoque más moderno es tener, lo que llamamos, una automatización fuera de proceso. Todas estas partes del navegador son realmente accesibles a través de APIs. Comenzó como un protocolo de desarrollador de Chrome. Y escribimos un programa externo que en realidad está controlando todas estas partes. Esto fue iniciado con Puppeteer en Google. Esto es lo que hicieron como una herramienta genérica que está escrita en Node.js y está controlando nuestro navegador a través de este protocolo. Y más tarde, el mismo equipo que estaba construyendo Puppeteer en Google se mudó a Microsoft y construyó Playwright. Y extendieron este protocolo, no solo para la automatización genérica del navegador, sino que realmente se centraron en lo que está disponible, lo que se requiere para las testing, como si tuviéramos una animación, queremos esperar hasta que se estabilice y solo entonces quiero hacer clic en el botón. Muchos de los problemas existían con todas las herramientas como Selenium. ¿Qué obtenemos con la automatización del navegador fuera de proceso? ¿Por qué es tan bueno? En primer lugar, tenemos acceso completo al sistema de archivos porque esto es externo y no se está ejecutando en el navegador. Esto se está ejecutando en nuestra máquina. Por ejemplo, en Node.js, podemos acceder a cualquier archivo. Podemos acceder a la prueba donde queramos. Podemos ejecutar en paralelo. De nuevo, este es un programa separado. No tenemos ningún problema para ejecutarlo varias veces tantas como sea necesario. Multi-idioma, no tiene que ser JavaScript. Esta automation que está controlando nuestras pruebas puede estar escrita básicamente en cualquier idioma. Puedes ver que en Playwright, tiene Python, .NET, y más. Tenemos control total porque estamos accediendo a través de la API. Tenemos control total sobre la security, la entrada, los servicios de ubicación, incluso sobre el archivo de performance, y así sucesivamente. Las interacciones son reales porque, de nuevo, estamos llamando a estas APIs. Estamos pasando interacción de la misma manera que nuestro sistema operativo las está enviando. No estamos limitados a solo una ventana o una pestaña donde se están ejecutando nuestras pruebas. Podemos generar tantas ventanas y pestañas como queramos y ejecutar la prueba sobre ellas. Entonces, diciendo todo eso, ¿qué significa eso para nuestras pruebas de componentes ZenUI? Esto es lo que estamos haciendo en ubiq. Estamos utilizando una combinación de Playwright y storybook, como di algunas pistas en el camino, para probar nuestro

6. Pruebas de Componentes con Storybook y Playwright

Short description:

Usamos Storybook para construir y renderizar nuestros componentes de forma aislada. Playwright es la herramienta que utilizamos para la automatización y pruebas del navegador. Con Playwright, podemos lograr una renderización real de componentes sin necesidad de simulacros. Proporciona estabilidad, ejecución eficiente y la capacidad de ejecutar pruebas en paralelo y sin cabeza. También podemos realizar pruebas de regresión visual y tomar capturas de pantalla. Storybook y Playwright están mejorando continuamente sus capacidades de prueba, incluyendo las pruebas de componentes. Las pruebas de extremo a extremo implican trabajar con un servidor de backend real y probar flujos de usuario completos, mientras que las pruebas de componentes se centran en variaciones y casos extremos sin depender del backend.

componente. Estamos utilizando storybook para construir nuestro componente y para renderizar nuestro componente de forma aislada. Construimos historias para cada componente y sobre estas historias estamos ejecutando nuestras pruebas porque a playwright realmente no le importa, siempre y cuando le des una página web, realmente no le importa lo que esté dentro de la página web. Solo necesitas proporcionar la URL y playwright la abrirá. Así que estamos generando nuestro storybook y luego sobre él ejecutamos la prueba y usamos playwright también para la automatización del navegador. Playwright comenzó como una herramienta de automatización del navegador solamente pero ahora también tiene un gran corredor de pruebas que tiene muchas funcionalidades realmente advanced y una gran configuración, y así es como realmente probamos nuestros componentes. Esto es lo que parece. No estoy seguro de cuán útil es eso, pero puedes ver aquí que lo tengo en VS Code y simplemente estoy ejecutando la prueba, abre la página, me muestra el componente específico y puedo simplemente ir y verlo. Veamos eso rápidamente de nuevo. Estás ejecutando la prueba dentro de VS Code. Puedes ver rápidamente que pasa y la prueba pasa.

Entonces, ¿qué ganamos con este enfoque? En primer lugar, esta es una renderización real de componentes, no necesitamos simular nada, el navegador se encarga de eso. Ya escribimos historias para storybooks para mostrar nuestro componente así que las reutilizamos y ejecutamos la prueba sobre ellas. Esta es una prueba muy estable, no necesitamos simular, Playwright proporciona un muy buen feedback Playwright proporciona mucha estabilidad en nuestras pruebas, obtenemos una ejecución eficiente, puede ejecutarse en paralelo, puede ejecutarse en headless, lo que significa que puede ejecutarse en el CI, también puede dividirse en fragmentos o puedes ejecutarlo en varias máquinas en el CI, básicamente tienes mucho acceso a todo, al igual que cualquier programa de nodo que quieras ejecutar. Playwright, y quiero decir que esto podría ser toda una charla sobre cómo el debugging y tracing advanced pueden hacer eso. Y obtenemos la capacidad porque esto se está ejecutando en el navegador real, podemos hacer capturas de pantalla y podemos hacer pruebas de regresión visual. Podemos hacer eso en Storybook, podemos hacer eso en Playwright y así sucesivamente. Solo quiero mencionar algunas otras cosas que también están haciendo, Storybook también está avanzando sus capacidades de testing, Playwright tiene pruebas de componentes por lo que puedes usarlo no solo para pruebas de extremo a extremo y lo mismo ocurre con Cypress, proporcionan pruebas de componentes. Para hacer esto rápido, podemos ver aquí que cuando hablamos de pruebas de extremo a extremo y pruebas de componentes, tenemos un navegador real y la migración visual puede lograr ambas cosas, pero la principal diferencia es esta, que en las pruebas de extremo a extremo probablemente trabajaremos con un servidor de backend real y haremos solicitudes a un servidor real y a una database y probaremos flujos de usuario completos desde la ordenación hasta el pago, pero como son tan largos probablemente nos centraremos en el camino feliz mientras que en las pruebas de componentes bloquearemos nuestro backend, no queremos ir a nuestro backend para ejecutarlo y hay muchas herramientas para hacer eso y nos centraremos más en la variación y en el caso extremo. Muchas gracias.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

TestJS Summit 2021TestJS Summit 2021
31 min
Test Effective Development
Developers want to sleep tight knowing they didn't break production. Companies want to be efficient in order to meet their customer needs faster and to gain competitive advantage sooner. We ALL want to be cost effective... or shall I say... TEST EFFECTIVE!But how do we do that?Are the "unit" and "integration" terminology serves us right?Or is it time for a change? When should we use either strategy to maximize our "test effectiveness"?In this talk I'll show you a brand new way to think about cost effective testing with new strategies and new testing terms!It’s time to go DEEPER!
TestJS Summit 2023TestJS Summit 2023
32 min
The Art of ‘Humble Views’: Testing React Native Apps the Smart Way
In this talk, we explore the divisive world of testing, where developers often find themselves torn between writing no tests and striving for 100% test coverage. Learn how to navigate these polarizing positions and adopt a more nuanced strategy that makes testing efficient and effective.We'll dive into the concept of 'Humble Views,' where we minimize untestable objects by extracting logic from UI elements into test-friendly parts of the codebase. This approach simplifies testing, focusing on business logic instead of UI complexities. Discover how the Model-View-Presenter (MVP) architecture helps achieve this, with presenters serving as a logical layer for testing and hooks aiding in separating logic from UI components.Throughout the talk, we'll discuss the trade-offs of this approach, the role of End-to-End (E2E) tests, and how to strike the perfect balance between too much and too little testing. Join us as we delve into the art of creating 'Humble Views,' ensuring that our React Native apps are scalable, maintainable, and effectively tested!
TestJS Summit 2023TestJS Summit 2023
29 min
Component Testing With Vitest
Testing is important. Proper unit tests can eliminate the chance for bugs to appear. But which testing framework will be suitable? Let’s explore how we can develop a reliable and efficient strategy for component development and testing with Vitest
TestJS Summit 2021TestJS Summit 2021
20 min
It's a (Testing) Trap! - Common Testing Pitfalls and How to Solve Them
It’s a trap” - a call or feeling we all might be familiar with, not only when it comes to Star Wars. It’s signalizing a sudden moment of noticing imminent danger. This situation is an excellent allegory for an unpleasant realization in testing. Imagine having the best intentions when it comes to testing but still ending up with tests failing to deliver you any value at all? Tests who are feeling like a pain to deal with?
When writing frontend tests, there are lots of pitfalls on the way. In sum, they can lead to lousy maintainability, slow execution time, and - in the worst-case - tests you cannot trust. But it doesn’t have to be that way. In this session, I will talk about developers’ common mistakes (including mine), at least from my experience. And, of course, on how to avoid them. Testing doesn’t need to be painful, after all.
TestJS Summit 2021TestJS Summit 2021
33 min
Test your UI in the REAL Browser
Imagine writing a complex function without unit tests. You would have to verify every scenario manually, over and over again. Cumbersome, but that's how most teams build user interfaces.
Imagine if you could build UIs and test UIs in the same place. If your components included expectations for how they were supposed to behave, you'd know the instant they broke.Storybook provides an organized approach to building UIs. You document a component's use-cases as stories, which are then rendered in isolation. Stories are like tests, but for UI. Storybook interaction testing allows you to script interactions and check expectations in the story itself. That allows you to run and debug UI tests in the same environment UI components are developed for: your browser.
React Summit 2022React Summit 2022
32 min
Design-Driven Full-stack: an End-to-End Dev Workflow that Scales
I’m going to show you something you haven’t seen before — a simple, integrated workflow made possible by React, RedwoodJS, and Storybook. We’ll start from scratch, generate code for components, design and mock state, then finish with a secure API and CRUD UI.
Sounds hard? It was. But not anymore! 🤯
You’ll learn how to bridge existing development gaps between stateful designs, data fetching, and your API using Redwood Cell components — a one-stop-React-shop for fetch, state, mocks, and design. Teams can move faster. Solo devs can iterate more quickly. And there are secondary benefits from documentation to security to accessibility, which add up to improving long-term maintainability at scale.
Get ready to be inspired by what you’ll be able to build!

Workshops on related topic

JSNation 2022JSNation 2022
148 min
Should we have business logic in the UI?
WorkshopFree
How many times did you say or hear “this is business logic, it should not be here”?In this workshop, we will create a modern frontend application using old patterns and you will learn how to build apps that have decoupled UI and services.We will start with a React application that has its whole logic in the UI. Then step by step we will extract the rules and operations to hit that sweet spot of independence.