Component Driven User Interface Testing (CDUIT)
Let’s grasp the component driven user interface (CDUI) before we begin testing the components.
To describe the movement in UI development towards component architectures and methods, software developer Tom Coleman coined the phrase “component driven” in 2017.
What is Component-Driven Development?
Component-Driven Development (CDD) is a development methodology that anchors the build process around components. It is a process that builds UIs from the “bottom up” by starting at the level of components and ending at the level of pages or screens.
Benefits
- Quality: By developing individual components and specifying their relevant states, you can test how well UIs function in various situations.
- Durability: By performing component-level testing, you can pinpoint issues in great detail. Compared to testing screens, it takes less time and is more accurate.
- Speed: Create user interfaces more quickly by utilizing pre-existing components from a design system or component library.
Complementary trends
Design systems have been around for years they’re coming into fashion now.
What is Design System ?
A design system is the single source of truth that groups all the elements that will allow the teams to design, realize, and develop a product.
Companies like Uber, Pinterest, Airbnb, Atlasssian and many more have achieve consistency in their UI through a component-based design system.
The benefits of a design system go way beyond UI/UX consistency. We could greatly accelerate and scale the development, improve the product quality, and greatly improve the work between developers, designers, quality engineers, and stakeholders.
Keep your underlying design system simple
Have multiple design systems. In a UI component ecosystem, there are various teams that construct and distribute their components. Have a standalone GitHub repository for your most fundamental design system, which was created by our design system team.
However, some teams require additional tangible components. In that instance, we could develop a distinct design system while still using the fundamental design system.
End-to-end testing
Let’s first discuss end-to-end testing and its difficulties before moving on to component testing.
What is end-to-end testing?
E2E testing is a technique that tests your app from the web browser through to the back end of your application, as well as testing integrations with third-party APIs and services. These types of tests are great at making sure your entire app is functioning as a cohesive whole.
End-to-end testing challenges
I’d like to highlight two common challenges in end-to-end testing.
- Maintenance of test cases: When we don’t refine our test pyramid based on the application in which we work, or when we don’t follow the test pyramid strictly, we end up creating as many test cases as possible. When an application changes its user interface, updating all test cases is exceedingly difficult.
- Slow Test: Compare to other tests end-to-end tests are slow because it goes through too many steps to perform test case, when it runs in real browser it takes much time to complete, and when we have more number of tests it will take more time complete it, When we execute end-to-end tests in pipeline, challenge that we have is system configuration, GitHub action hardware specification for Windows and Linux virtual machines is a 2-core CPU (x86_64) with 7 GB of RAM. If we spin up more browsers for parallel execution, it will slow down the test. Adding to it, if we want to perform cross browser testing at the end-to-end testing level, it adds more time to testing.
Move fast and don’t break things
We must have a sufficient number of tests at the necessary level to not break things.
Let’s test the component
When components are developed autonomously and pages are built by composite components. Then why do we test the application page directly without testing components?
What is CDUIT?
In component-driven Driven User Interface Testing (CDUIT), we merely mount the component we want to test and concentrate on evaluating just the functioning of the component, not bothering about the whole operation of the application.
How does it work?
Automation tools like Playwright and Cypress have out-of-the-box support for component testing.
Playwright or Cypress will create a list of components that the tests need It then compiles a bundle that includes these components and serves it using a local static web server. Instead of visiting a URL to pull up an entire app, it just navigates to the facade page.
While components run in the real browser. This brings together the best of both worlds: components run in the real browser environment, real clicks are triggered, real layout is executed, and visual regression is possible.
Benefits of component tests
- Easier to test components in isolation
- It’s super fast and reliable.
- Don’t rely on any components or external system(APIs) to run
- Usually written by developers while working on the component, we are able to find bugs in the development stage.
- Cross-browser testing can be done at the component level, so we don’t need to do the heavy lifting at end-to-end testing.
Refining the Test pyramid based on the component test
When you add component testing to your test pyramid, a sizable portion of your current end-to-end testing test cases and unit test cases will be converted to component test cases.
Unit tests vs Browser test(component test/end-to-end test)
I think the distinctions between unit tests and end-to-end testing should help you make your decision on writing tests.
- If a unit test requires a lot of mocking and you have to use tools like
jsdomorenzyme, to simulate a real-world environment, you may want to rewrite it as a component test.
End-to-End vs Component Tests
For instance, we will use the date picker component to understand end-to-end test scenarios and component test scenarios.
Possible Component test cases for date picker
- Verify that when a user clicks on a date field, a date picker appears.
- Verify that the user is able to select a date from the date picker.
- Verify whether the current date is automatically selected when the date picker opens.
- Verify that the date picker closes once the user chooses a date from it.
- Verify that the date picker closes when the user clicks outside the date field.
- Verify that the user can modify the date after choosing it using the date picker.
We can add test cases for date formats too
Accessibility test cases
- To check the support for keyboard hotkeys:
tabto switch between inputs, arrows, month-year select, and day grid. escape to close the datepicker. - When month and year selects focused,
upanddowncauses dropdown to open and move to value,enterandspaceto choose selected year or month. - when the day grid is focused,
left,downrightandupto move through the grid days.Enterto pick a date.
Early on, this case was part of an end-to-end test suite, Now it’s moved to a component test.
So now we are able to fix bugs in the development phase itself. Component tests are super fast and reliable to execute because they focus only on the component that we want to test, dependencies are removed, and there is no login to the application to test the component.
End-to-End test cases
End-to-end test cases should be taken care by the consumer of the components.
In end-to-end test, we will verify how the application behaves based on the value from the date picker.
- If it’s a calendar application, after we choose the date from the date picker, it should move to the particular date, We can verify this navigation.
- If it’s a calendar application and the date picker is from the appointment widget, then it should create an appointment on the particular date selected.
We could add a few more cases.
After Refining the Test pyramid
Now we have constructed the test pyramid the right way. The result is the right ratio of test cases in unit, component, and end-to-end. Now our tests will be healthy, fast, and relatively easy to maintain.
Our end-to-end test suite will be slim and healthy. Now continuous testing will be a reality.
Now our CI/CD pipeline will be healthy, and we will have confidence in our testing and the build.
Note: Soon I’ll add Part2- How to do component testing with the playwright
