ch04-HeaderBar
Last updated
Last updated
In the Angular version of the app, there is a parent component above HeaderBarBrand
. Let's create it too.
Create a branch feat/headerBar
. Create 2 files under src/components/
folder; HeaderBar.cy.tsx
, HeaderBar.tsx
. As usual, start minimal with a component rendering; copy the below to the files and execute the test after opening the runner with yarn cy:open-ct
.
In HeaderBar
component, which is the child of HeaderBar
, we added a top level data-cy
selector with the value of header-bar-brand
. Let's add a failing test to check the existence of the child component (Red 1).
Insert the child component into the parent.
We get the same react-router
related error that we got with the HeaderBarBrand
component. If a child component is using react-router
, when testing the parent component, we also have to wrap the parent in BrowserRouter
(Green 1).
The child component renders.
The specification shows that the child component is wrapped by a header
and a nav
There is also some css that gives it the dark theme. We can copy those off of the browser. We also add a data-cy
selector to the top tag of the component.
The component is looking great with CSS.
Realize that we did not necessarily go through a traditional RedGreenRefactor cycle; our Red in this case was the component not rendering in its final form and we kept improving that step by step.
What else can be tested at this point? We do not need to repeat the tests for the child component, because we covered all of it at the child. The only valuable additional check would be to check for an attribute of the nav
tag. We can easily add that with Cypress testing library (Refactor 1).
The main takeaway in this section is the parent-child relationship between the components, and a demo of how top level data-cy
selectors make child components easier to reference in higher level tests.
If a child component is using react-router
, when testing the parent component we also have to wrap the parent in BrowserRouter
.
In a parent component, we do not need to repeat the tests for the child component, because we covered all of it at the child. The same thought process applies to higher level tests with e2e.
When designing the component, we do not necessarily have to go through a traditional RedGreenRefactor cycle. When our test tool is also the design tool, our RGR can as well be incremental visual enhancements to the component whilst adding classes and css.