Transcript from the "Integration Testing Q&A" Lesson
>> Kent C. Dodds: Okay, yeah, so the question is from Francis and it's regarding the guiding principle of the react testing library, the DOM testing library is that phrase that I say. The more that your test resembles the way your software is used, the more confidence it can give you. And so the question is okay, so how does that apply to a component library?
[00:00:26] Or even one that doesn't expose any why. And so the user isn't gonna use that directly. So in those situation I consider the user to be the consumer of the software, so the developer who's using it. So it's kind of a fancy way to just say, test your component as if it's a black box.
[00:00:45] And only test the public facing API, don't worry about any of the implementation details. And so, yeah, when I'm building a component like Downshift is a component that I've been working on a lot, it's autocomplete library. It's not actually used directly by end users. People have to use it to create experiences for end users.
[00:01:06] So I just use the public API. A big part of the API is that the children prop is a render function. And so I actually make that a spy and I make sure that that is called in the right way when I'm testing it because that's part of the API.
[00:01:24] The props are part of the API and so I interact with it in the same way that the software's going to be used. In that case it'll be used by other code props and the children prop.
>> Kent C. Dodds: Cool?
>> Kent C. Dodds: And somebody's asking do you use jest/no-large-snapshots? They're referring to an ESLint rule.
[00:01:49] Eslint plug in Jest. It's a great collection of jest rules for ESLint so I suggest that you use these. One of these is no large snapshots. Yeah, right here. So yeah, you can set a limit for how big your snapshots can be. I actually haven't added this yet to anything.
[00:02:19] I probably will eventually. Yeah, so something to look at. eSsence is pretty cool for things like that