检查Playwright内的组件(ReactJS)中的props值

huangapple go评论77阅读模式
英文:

Check props value from a component (ReactJS) inside of Playwright

问题

I'm fairly new to E2E testing. One of the things I want to test is when I change the shipping address I also want to set it to the billing address.

例如,如果我在输入字段中设置Grove Street作为我的送货地址,我也希望它成为账单地址。

Is there a way for me to check the billing address as well as the shipping address that way?

有没有办法让我检查账单地址和送货地址?

Here is my component:

这是我的组件:

const Delivery: React.FC<DeliveryProps> = ({ data})

and that data is modeled like this

数据模型如下:

data = {
...some other data
shippingAddress: string;
billingAddress: string;
}

I would like to fill the address field like so:

我想这样填写地址字段:

await checkout.verifyAddressInputField(page).fill('Grove street');

And to check the props value of my whole component, specifically the data props shippingAddress and billingAddress.

然后检查整个组件的属性值,特别是shippingAddressbillingAddress的数据属性。

英文:

I'm fairly new to E2E testing. One of the things I want to test is when I change the shipping address I also want to set it to the billing address.

For instance, if I set Grove Street as my shipping address in the input field I also want it to be the same for the billing address.

Is there a way for me to check the billing address as well as the shipping address that way?

Here is my component:

const Delivery: React.FC&lt;DeliveryProps&gt; = ({ data}) 

and that data is modeled like this

data = {
  ...some other data
  shippingAddress: string;
  billingAddress: string;
}

I would like to fill the address field like so:

await checkout.verifyAddressInputField(page).fill(&#39;Grove street&#39;);

And to check the props value of my whole component, specifically the data props shippingAddress and billingAddress.

答案1

得分: 1

请找到需要翻译的部分:

"Don't check props! E2E testing shouldn't know or care that the site even uses React. The idea of testing is to interface with the application like a user would (interacting with the web page), not like a programmer would (interacting with component props).

A typical Playwright test looks like this:

  • Navigate to the page, say, a login page
  • Assert that a form has appeared on the page
  • Fill in the username and password for a sample user
  • Click the login button
  • Assert that the page navigated to a dashboard

None of these steps involve anything related to React--it's an implementation detail. In theory, we should be able to replace React with vanilla JS, Angular or Vue and our tests would continue to work.

Tests that are heavily tied to implementation details can often break in surprising ways and don't provide confidence that our app necessarily works well from the user's perspective.

Even when unit testing React components, there's no need to assert on props. Enzyme was the unit testing library popular in React 16 that promoted testing implementation details, but it's been supplanted by React Testing Library which interacts with the component purely through its interface. RTL lets you provide props because it's typically used in a unit testing capacity, but with Playwright, you don't need to do that. Components are involved in the E2E flow but we don't test any single one specifically as in a unit test.

Furthermore, Playwright wants you to avoid other implementation details like CSS selectors since they're not user-facing.

Further reading:


As for your specific use case, it's not entirely clear what user-visible behavior should occur when you type in the form. But if you can submit the form and see a confirmation page, then that's a test. If there's some invalid information you can enter, then submit the form and see an error message, that's another test. If typing in the form triggers some validation message like "password must be at least 8 characters", that's a test.

One thing that's probably too fine-grained to bother testing in an E2E test is whether filling out the form renders text in the input for a controlled component. We can infer that if the form is submitted successfully when it should be and rejected when invalid, the component's inner workings are behaving as expected.

If you want to test fine-grained input masks and validation on that component, I'd probably do it in a unit test suite with React Testing Library. E2E tests are slow and are more about the overall application behavior than covering every corner case of, say, a form input."

英文:

Don't check props! E2E testing shouldn't know or care that the site even uses React. The idea of testing is to interface with the application like a user would (interacting with the web page), not like a programmer would (interacting with component props).

A typical Playwright test looks like this:

  • Navigate to the page, say, a login page
  • Assert that a form has appeared on the page
  • Fill in the username and password for a sample user
  • Click the login button
  • Assert that the page navigated to a dashboard

None of these steps involve anything related to React--it's an implementation detail. In theory, we should be able to replace React with vanilla JS, Angular or Vue and our tests would continue to work.

Tests that are heavily tied to implementation details can often break in surprising ways and don't provide confidence that our app necessarily works well from the user's perspective.

Even when unit testing React components, there's no need to assert on props. Enzyme was the unit testing library popular in React 16 that promoted testing implementation details, but it's been supplanted by React Testing Library which interacts with the component purely through its interface. RTL lets you provide props because it's typically used in a unit testing capacity, but with Playwright, you don't need to do that. Components are involved in the E2E flow but we don't test any single one specifically as in a unit test.

Furthermore, Playwright wants you to avoid other implementation details like CSS selectors since they're not user-facing.

Further reading:


As for your specific use case, it's not entirely clear what user-visible behavior should occur when you type in the form. But if you can submit the form and see a confirmation page, then that's a test. If there's some invalid information you can enter, then submit the form and see an error message, that's another test. If typing in the form triggers some validation message like "password must be at least 8 characters", that's a test.

One thing that's probably too fine-grained to bother testing in an E2E test is whether filling out the form renders text in the input for a controlled component. We can infer that if the form is submitted successfully when it should be and rejected when invalid, the component's inner workings are behaving as expected.

If you want to test fine-grained input masks and validation on that component, I'd probably do it in a unit test suite with React Testing Library. E2E tests are slow and are more about the overall application behavior than covering every corner case of, say, a form input.

huangapple
  • 本文由 发表于 2023年4月19日 21:46:07
  • 转载请务必保留本文链接:https://go.coder-hub.com/76055298.html
匿名

发表评论

匿名网友

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen:

确定