Video details

JS Monthly #17: Lewis Prescott - Double up your component & integration tests with Supertest & Nock

JavaScript
10.22.2021
English

This talk builds on my course for Test Automation University (https://testautomationu.applitools.com/javascript-api-testing/) Using the power of mocking and the tool Nock. You can build component and integration tests with one set of scripts. I will show you how this is possible and also explain the difference between component and integration tests. In order to make your tests fast and build tests at the right level, use the power of mocking.
The JS Monthly Meetup was organised by
Aris Markogiannakis (JS Monthly host) and hosted by Prisma. ✨ Join the Prisma Meetup group here: https://www.meetup.com/js-monthly/
Follow Lewis:
Twitter: https://twitter.com/WuigPrescott
Next: 👉 Check Previous video: Heavily Connected Data Applications - https://youtu.be/D7C-97HgXTs

Transcript

The first speaker is going to be Louis Prescott. He's going to talk to us about the double up your component integration test with the super test and not. I would like to invite Louis on the steps and talk about this amazing stuff. Hey, good to see you again. Yes, me too. It's been a long time, and I'm so glad to have you on the meeting. Arisa taught me at CityUniversity fourstack. Net and Reactcourse. You're going to teach me today. How can I double up my looking forward for that? I'm going to go off and I'm going to grab a drink and I'm going to have all my ears open and look at your amazing thank you very much. I'm just going to start sharing my screen. Right. So thanks, everyone. I'm looking forward to sharing with you doubling up your component integration tests. So what do I mean by that? Let me tell you a bit about me first. So I am a QA lead currently at Syracair, and I do all kinds of testing. I work with all kinds of technologies, so I'm not just a JavaScript guy. So hold off on me if you see any code. That is quite terrible. So last year during the pandemic, I was working for Cancer Research. Cancer Research is a large charity within the UK, and I was on furlough 20% of the time. So I got the opportunity to spend time creating an online course, which is the first time I've done that. And it takes a lot of hours to create a course. But obviously it puts me up with all of these leading people within the test industry and probably people you know, like Andrew Jones, who runs the test or Special University. Previously, I also worked for Asos where I learnt my trade in development and things like that. So, yeah, that's a bit about me. So what are you going to learn today? Hopefully, you will learn a bit about super test and how you can test your APIs using JavaScript, how you can use knock to knock out some of your API requests. And then by optimizing with this, you can also turn your component test into your integration test. So how did I discover this? Back in the day when I worked at Cabinet Research, we had multiple components for our application. So if you think about a charity, we have fundraisers. In order to have a fundraiser, you have to have an event and you have to have people fundraising for that event. So when you're creating your microservices, we split it into two teams. One is for our fundraising pages, and one is for creating our events. So when we come about testing that from an end to end solution, we want to test it with the events for our fundraising pages. So we have that dependency in our microservice and nobody's got time for testing right at the end of the day, we need to make it as easy as possible for the fundraising team to be able to create fundraising pages as part of the test in order to make sure that we're rolling out our new features really quickly. So I looked at creating an API wrapper. So in order for us to run our end to end test, we're running in Cyprus, we needed to have access to the APIs and the integration that the Events team were looking after. So it's a completely different repository, and we already knew that the unit component and the integration test were covered within that first repository. But what we didn't know was that end to end solution how that would work across microservice teams. So I created an MPM package. So within that NPM package that allowed us to share that wrapper with all of the teams that relies on that core Events team. That meant we could consume that within our acceptance test, and we could easily go about our testing. So this is kind of coined in a source. So GitHub came into Asos and talked to us about inner source about wrapping your kind of helper functions and also wrapping your reusable components so that you can use them within your organization and not have to worry about things like authentication and things like that, because that is all encompassed within your inner repository. So let's get into what the talk is all about. So super test is a really useful tool, just a wrapper around the request library, which allows us to make assertions on our request so easily. We can test our API and make sure that any request that we're making has the expected output. So this is a really simple example, and you can see the two different types here where we can just chain the request to the assertions, and then also we can do a bit more. We need to dig into the response bit more. We have the callback function. So where does Knock come in? So Knock is a library which allows us to intercept those API requests and reply with a response. So your traditional mocking of okay, this is what requests we're making inside our tests, and this is what we want the reply to be. So this is really useful in terms of obviously, when you're rendering your components or you're making a call out to a third party system that you don't want to make a call out to, we can use this library to allow us to do that. So the other thing that's great about Knock, which I discovered when I was using it. So going back to the API wrapper, the API wrapper that I built had component tests, and it had integration tests. So this allows me to make sure that when I was making any changes for that API wrapper, which now has consumers right, people within the charity would be able to use it. So I didn't want to break anything if I was changing the version or whatever. So I had these tests built into the actual repository itself and knock off. True is the environment variable, which allows me to switch between using my mocks and actually hitting the API endpoint. So within the CI pipeline, I wanted to make sure that I can actually hit a real environment that exists in the charity's ecosystem, and I wanted to make sure that my opponent test run to make sure that I hadn't broken any functionality that I had built inside the wrapper. So what we mean by component and integration test? Just to be super clear, the component test is just limiting it to the specific code that I've written. So when we're talking about the API wrapper, I'm not making any calls out to any external dependencies. I'm just testing that specific function. Martin Fowler said about this was in theory, a system with excellent component tests, and this was a really simple wrapper that I was building. It had no real logic applied to it should be coverage. It should be bug free, right? But that's not always the case in practice. There's lots of things that lurk around in the interactions between components, and that's where the integration tests come in. So we want to determine whether the units that have been built integrate together and work seamlessly. So as I mentioned, things like authentication or any configuration that I'm putting inside the API to launch it or anything like that that needs to be tested from an integration level. So the benefits of mocking are the stability of my tests and the reliability that my tests aren't going to break if someone makes a change to the environment that I'm testing against. So it's super reliable. And integration tests inherently have dependencies that you can control sometimes obviously with dockerizing things or things on container. You can obviously mitigate that risk and third parties. So in my current role, we work a lot with third parties. We're a startup with Clailing massively. We've purchased a few things to get us off the ground. So third parties are inherent inside our testing, and we don't want to be testing those. Right? They're what we pay for. So we just Mark those out. So. Integration has its own kind of difficulties, but marks don't test everything. So what I want you to do now is go to Menti dot com and use the code or use your QR reader. So when you want to answer two questions, the first question is this one who does component and integration testing on their front end, and then the second question will come back to later. But it's just about some conversations that I've had recently that I'd like to discuss with the community. So yeah, this is just research for me, really, to discover whether what we're doing is what everyone else is doing. Yeah, someone said mine would be neither. And I forgot yesterday I meant add, don't know or none option. I didn't add that. So yeah, I'll assume there's also some people saying that's interesting with the component testing. So in my experience, front end guys have often done component testing and seeing that as kind of the assurance that what they've built is good. Right. And the rest of it is down to the responsibility of someone else. But that's interesting. It's good to know. So as I mentioned earlier, another benefit of using Knock, right. Is that we can use it inside our JavaScript framework. So I'm using React here. So we've got access code to get users so we can use it in both ways that I've just described using that knock off environment variable, so we can use it to return the mock that we're expecting. So we can check that the React component renders successfully. Also, we can check that in RCI pipeline. When we want to run a smoke test against our React app, we can knock off, and then we can actually hit the real API endpoint to check that it's worked successfully. So I'm going to show you how that works now. So we've got this super simple test I said earlier to not knock me on my JavaScript skills, so it just loads the user's component finds a specific text. So I've got this React app, which renders me a list of users. So we're just going to find my email address, and we're not going to expect that to be in the document. I don't think I have increased the size of this, unfortunately. So it's pretty small. Sorry, I'm having a bit of a malfunction. Here we go. So if we go into the app and we run NPM test, the NPM test command is running the knot test, so it's going to return the Knots component so you can see it's rendered the users. This is this test here. So I'm replying with knock at knock. Com and that returns me the so now if I run my smoke test, this is turning knock off. And so this is going to hit the real component, and I've got my server running in the background which renders my list so you can see how it would work. So coming on to my next question that hopefully you've all answered. So who is responsible for integration testing? I offer the word cloud, but maybe that's not what I should have done in my experience. Usually the API kind of back end is usually doing the integration testing and QA in some instances, but yeah, absolutely agree. Everyone should be. And it's definitely a developer. It's just which developer we're talking about. So in my opinion, I think that the client. So we're talking about the front end, for example, in this scenario should be responsible for the API test from the request that is made, and also what they expect the response to be because that's what's going to be rendered right. Usually the API has tests which check that what they're sending has the correct response. I think it should be flipped because I'm a big ambassador of contract testing with Pact and consumer driven is the way that I think microservices should be built. And yeah, if you've got more questions about that, then you can feel free to tweet me or whatever and all good. So that's it fire ask any questions. And welcome back, Aris. I think. That was great. Thank you very much. So yeah, it's a big question currently. So it's quite a big question because a lot of big teams have dedicated people like testers that they do the test, like developers normally code. And then there's the person that knows everything about the app and that person does the full journey and test and everything. And you're just a person do everything for you. Daniel, what do you think of the talk? What is your thought? That was very awesome. I'm a software engineer as well. I've worked many years in the front end. Not right now. I'm working more in the back end, but I know the importance of developing your tests and knowing what you're doing, not only relying on QA to do all that and understanding what you're doing. I've used many tools to try to test on the front end somewhere. We're more finicky, but yeah, I believe more and more we are seeing the value of testing our applications doesn't matter the size. You can always take some value out of that. So yeah, it was very interesting to see it all. Great. Thank you. So there's a question, but I don't know. How is it related how we can perform just maybe that's for later on for Daniel, you have to wait just ten minutes to see the next talk, and then we will answer Daniel this question. I know you told us a bit about the company you are working, but could you tell us a bit more about where you've seen being quite useful and how we could use it because they're like big companies. They rely on one person, but that Knock and could help them with their software development. Yeah, absolutely. I think where it really came into its own, for me, was the ability to write a single set of tests, and I could run them as component test and integration test. And I think that's where a huge amount of value comes in is getting that double value from your test. We have a suite of tests currently in Cyprus where we are stubbing out all of our integration points. Right. But this means that we're not actually testing the application as it's going to be used. So I think that's where tools like Knock can really come into their own is allowing you to have that flexibility of do you want to test this against the real implementation, or do I want to control what I'm testing? What do you think of coverage, test coverage, and what do you think of what is your percentage in terms of discovery. I don't like to look at a percentage, but what I like is the Kent Dodge Testing Trophy. So have a lot of integration tests, have some unit component tests, and then have a few end to end tests at the top. Obviously. Now with languages like type scripts, static, your static typing is still tested. So you don't have to worry about the coverage of nulls and stuff like that. I'm asking you this because once I went to an interview and the top guy in the company asked me, so what is the percentage of coverage that you. I believe that's out of the rules. It's just like you don't ask a woman her age. You don't ask a developer. What is that coverage? No, I'm using the existing laboratory. Yeah, definitely. I think it makes it super easy to select the elements. Super easy to work with, interacting with the page. It just adds that layer to make testing easier. Again, what would be your advice to front end developers and JavaScript developers that they're looking at right now from a test point of view? Because. Since I know you are like the test guy that knows how to do stuff in the test world, what would you advise them? So I think what is very clear for me at the moment is tools like Cyprus make it super easy to test it. But that doesn't mean that that's what you should choose. So you should always choose the right tool for the job. And yeah, as I mentioned about things like if you're working with a lot of third parties, then you don't need integration tests. Right? You stuff out everything. So don't write them. So yeah, I think that's the thing. Some people jump on board with the testing tool because it's easy to use. But actually, it's probably not the right tool. Daniel, do you have any questions for Luis? Yes, I do actually have one regarding what you just talked about regarding Cypress. Do you feel like Cypress would be a tool to complement what you just talked? Or do you think it's something separate? How do you see? Because in my personal experience, I use Cyprus a lot. I started using Jest, but I came up with I didn't come up with, but I saw the philosophy that when you're working on the front end, you don't necessarily want to see if one function is working properly, but you want to know if the entire workflow is working properly. So you don't want to know if the function that is triggered when you click a button is working. You want to know if when you click the button, the thing that should be happening is actually happening. So how do you see that? Yeah, that's a great question. So what I always think about in terms of that is the feedback loop. So how fast do I want the feedback of what I am developing? So as you mentioned about the interaction of it in the page. That's super important right before I go to push this out to an environmental push this out to production. But if I got a very small function that I just want super quick feedback on, I'm going to make these tweaks then a component that would probably suit that purpose. Does that answer your question? Yes. I believe it does. Thank you very much. That was quite informative. The whole talk and the Q and A. We're going to jump now to the next speaker. Luz, thank you very much. Thank you. I hope you stay and we will have a chat with Daniel afterwards. And it's nice to see you again. And Congratulations. It was a good talk. Yeah. Great to see you again. Hopefully in person. Next time. Yes. For a beer in person.