用笑话和酶进行稳健的测试

Question

I'm currently trying to improve the tests within a react project in which I am utilising Material UI. I am utilising jest and enzyme to perform the tests.

So far I've been using the .find to find the components, to perform actions on. Recently I've stumbled upon an annoyance/issue that I have been unable to find the answer for. To pick a certain scenario I've chosen the one here below:

I have a form in which a user inputs

• first name
• last name
• email
• phone number
• and so forth...

I am creating a wrapper for this form and the most reasonable approach for finding the fields to .simulate('change') have been to take the wrapper and doing the following:

// Arrange
const formWrapper = formWrapper(); // <--- A mount function to create the above described form
const firstNameField = formWrapper.find('input').at(1); // <--- This is currently my issue
const lastNameField = formWrapper.find('input').at(2); // <--- This is currently my issue
// ... and so forth

// Act
firstName.simulate('change', { target: { name: 'firstName', value: 'Bobby' },});
lastName.simulate('change', { target: { name: 'lastName', value: 'Brown' },});
// ... more simulations ofc

// Assert
// ... and some expects.

My annoyance is the way that I'm "fetching" my inputs. The only reason I know that the firstName field is .at(1) is because I've looked into the HTML. It is not a very robust method. If I need to update that form, then the entire test will break, and I will have to figure out which fields are which once again.

A small note is that I am using the Material UI Text Fields as my base component, but I have styled them after my requirements. I've tried passing in some custom prop to my components (eg test="firstNameField" ), but that is not a pretty solution as Material UI passes that along to all the child components. If I do this I could of course always just find .at(1) if I make the custom prop unique to each field. However I don't think this is the way to do it either. There should be some other way that I am not aware of yet.

So my question is:

Does someone know a more robust way to do this?

EDIT:

After reading comments and suggestions, I've found that I might have been too specific in my question. Of course the example (with inputs above), is one of the problems that I face, but this is also the case with other components.

Let's say that I on my above described form element, have two identical components (typography fields - more specifically paragraph tags), that both consist of the same base component, how would I go about differentiating these two? Would I be forced to give them unique IDs or is there some other way? And even if I did give them unique IDs, those would be passed down to all the children that the Material UI components have.

Answer 1

You can use react-testing-library which gives you queries to select based on how user would interect with your app, in your case your form.

for example if you want to get your name input and you have correct htmlFor for your label you can use

const nameField = getByLabelText('name');

Answer 2

Okay.

So after some much research and documentation read-through I found that you can simply chain your .find() 's, and if you think that is not enough you can also use the .findWhere() if that more suits your flavor.

So in the end what I ended up doing was to fetch the "field" which had the property name: 'firstName and which was an input field.

The following code snippets illustrate:

const firstNameField = formWrapper.find({name: 'firstName'}).find('input');
const lastNameField = formWrapper.find({name: 'lastName'}).find('input');

const firstNameField = formWrapper.findWhere(n => n.name === 'firstName' && n.type === 'input');
const lastNameField = formWrapper.findWhere(n => n.name === 'lastName' && n.type === 'input');

This method removes the excessive amount of nodes from Material UI (all the children that has passed props from their parents).

I also found documentation pointing towards using the modified "enzyme" package that Material UI has built in, but so far that didn't change anything, regarding my issues, and the regular enzyme package works just fine.