[Table] Snapshot test issue with TablePagination

[is1ash]

Recent changes to compnent TablePagination break test.

https://github.com/mui-org/material-ui/blob/3eb02f5498857bd01bb7924eed9b946f33e39052/packages/material-ui/src/TablePagination/TablePagination.js#L114-L116

The generated id is always new and snapshot doesn't/cann't match.

<p 
  class="MuiTypography-root MuiTablePagination-caption MuiTypography-body2 MuiTypography-colorInherit"
-  id="mui-7460"
+  id="mui-62542"
>

• The issue is present in the latest release.
• I have searched the issues of this repository and believe that this is not a duplicate.

Environment 🌎

@material-ui/core: 4.10.1
jest: 24.9.0

[eps1lon]

Auto generated ids have no guarantee to be stable. This is another reason why we don't recommend snapshot testing.

[oliviertassinari]

Up until now, we have been providing ways to get deterministic snapshot tests, requiring extra work.

As far as I know, this occurrence of the problem is unique. It's the first time we don't provide any workaround. It sounds like the position of Material-UI is shifting from we discourage snapshot to we prevent it. Should we document it? Should we provide an escape hatch? It will be interesting to see if useOpaqueIdentifier is snapshot friendly when released as stable.

[eps1lon]

It's the first time we don't provide any workaround.

<TablePagination SelectProps={{ id: 'stable-select-id', labelId: 'stable-select-label-id' }} />

[oliviertassinari]

I have updated my comment on #17070 (comment) to include this problem. It will help when revamping https://material-ui.com/guides/testing/.

@eps1lon Are you sure that #21293 (comment) works? it seems that it won't solve the issue with the Typography. So does it mean that we do no longer support snapshot tests?

EDIT:

https://github.com/mui-org/material-ui/blob/fdd859c7e5d0007c3508012e0e4f93e6d12ffa1f/packages/material-ui/src/TablePagination/TablePagination.js#L119

[eps1lon]

So does it mean that we do no longer support snapshot tests?

We never did and we shouldn't start. It restricts us for something that shouldn't be done in the first place.

[oliviertassinari]

@eps1lon Looking at the issue history around snapshot tests https://github.com/mui-org/material-ui/issues?q=is%3Aissue+snapshot+tests+, it's seems that there is a non neglieable demands for it. This makes me think that no matter which direction we take, I think that we should write it down in the testing guide documentation. Developers should be able to find the information (this is the main outcome I was looking for with my comment in #21293 (comment) 🙂)

Now, I though that we were supporting snapshot tests, e.g. https://github.com/mui-org/material-ui/pull/16523/files#diff-ee6298306b47efa1a027a3bc93186d60R152 (meaning it was possible without being easy) and I was curious about this tradeoff. Should we do the extra mile for developers that think it's helpful for their case or shouldn't we? My initial intuition is to say that if React allows it, we should too, as long as the overhead is small. Which seems to be the case.

I any case, I'm all in for warning developers about the limitations of it and how painful it can be down the road, that they might lose time, have a false feeling of security, etc.

[eps1lon]

I'm tempted to say that if React allows it, maybe we should too, as long as the overhead is small.

What does this mean? You mean you want to support snapshotting the component tree? Because that is even more restrictive than snapshotting the DOM.

It would mean we can't make any change to the render output without breaking tests.

Looking at the issue history around snapshot tests https://github.com/mui-org/material-ui/issues?q=is%3Aissue+snapshot+tests+

You already said it: "history". create-react-app no longer has a snapshot test in the default template but uses @testing-library/react. I don't think we have the bandwidth to support snapshot testing.