All You Need Is a Contract…

Okay, so let me just clear up the room. There's not going to be contract testing here. This is a joke we were talking before coming on stage. Also, I'm going to move a lot, so I'm trying to figure out the spot. That's cool, if I don't get blinded by the light.

Before anything else, React Advance, thank you so much for having me here. It's a pleasure. I'll walk around for that spot because apparently the camera won't get me on the other one, so I'll try not to move a lot.

I just wanted to start this talk with like, I would like to give a cheerful applause, because there was so many hard work setting up this conference for everyone from Git nation, everyone from the tech team. I don't know if you're aware, but when we started today, we were having some issues plugging everything, and now everything is working up already so far, so can I get an everyone that's working on this? Okay. Thank you so much.

So, let's start this because already one minute went away, and there are really three things that annoy me as a developer. The first one is when you have unmaintainable code. You know the feeling. Your code is not really that good sometimes. The more you add, the worse it gets. It's struggling. Yeah, it's hard. And then the second thing that really annoys me, it's when that unmaintainability finds a way of getting into your tests. Now it's not bad that your code is not good, your tests are not good as well. Probably you're not sleeping that well at night because you know what flaky tests feel like. And the third thing that really annoys me, and I'll promise to not start a rant here, is when you have a task that arrives late into the sprint. I know some of you relate to the feeling. Let's picture we have a team where two parts are working on a task and the first part takes 98% of the time, and once the task gets to you, you have 2% of the time. So obviously your product manager is going to expect you to deliver that thing yesterday. And this is a feeling that I could start talking about here and I wouldn't stop.

So let's continue, because I have a story about how me and my team fixed these issues a couple of years ago. So let's start at the beginning on how we had just cleared up the first issue. Me and my team had just defeated the unmaintainable code monster. Because this had been something that is been working around, it was threatening us, it was hard.

And what was the reason? Well, the reason was server state. Now, I don't know if you are aware of what server state is. It's typically the state that exists somewhere on the Internet as external to your application. And it has a bunch of challenges. Caching, deduping requests, data prefetching. There is a maintainer here from React query which you can talk about of many of these challenges and you can probably understand how much pain it is understanding and having to implement this thing by hand and I can tell you that me and my team, we didn't have React query back then or in the beginning, we didn't. So we were implementing all of these things by ourselves and the more code we were having, the worse got the unmaintainable code monster. So we started thinking, why are we implementing this ourselves again? What are we trying to prove to going in this direction? And well, a couple of months went by and this was when a couple of, well, these months went by, a co-worker, like the King Arthur in the Sword and the Stone movie. I think that's how you say it in English. Sorry, non-native English speaker here. One co-worker approached the stone and brought out a 10-stack query. So apparently, this new thing, React query, had just come up and it was the solution for our issues. And 10-stack query brought harmony to our code because now all the stuff and issues we had with server state were solved and we didn't have to worry about implementing that thing for a while that is.

Now, a new threat was lurking in the shadows. You see, that unmaintainability found a way outside of our code and going inside of our tests. Now, I don't know if you remember this image I showed you a couple of minutes ago, but this is Hydra. And you know what they say about Hydras. Cut one head, two more take its place. And this is kind of what was starting to happen with us because now our tests were not just unmaintainable. They were flaky. They were complex. I couldn't sleep at night because I had no trust on what the heck I was doing and now you're wondering, okay, what's the relation? What are we going to see? Well, safely now, a couple of years ago I can tell you that me and my team managed to fix these issues. And the fun part was that all we needed was a contract. So this is the part where I actually start the talk.

Let me just introduce myself real quickly. I'm Daniel Alfonso. I'm working as a developer advocate at OLX. I'm an AGIT instructor and an out-there ambassador and you can find me, I'm going to say Twitter because of the pool before on Twitter and pretty much any social network at the end So Daniel GC Alfonso. Also something about me, I recently published a book called State Management with React Query. Thanks.

I would also love to talk to each of you about React Query because you're going to see from this talk it's something that I really love. Another thing, I'm all up for sharing love. And I want to thank Joshua, Mateus and Tejas because they gave me feedback from previous versions on this talk and this made me able to improve it and have the talk that we have today. So please stay tuned for that talk. So can I get an applause for them. Just there sharing the love.

Okay. Real quickly because five minutes went by. This talk is going to be case study. I'm going to show you some of the stuff. I already showed you some of the issues that me and my team had and how we fixed them. Obviously, while I'm presenting, some of you might be thinking, oh, I wouldn't have done it this way or probably I would have done it this way. Well, that's the thing with implementing and doing software nowadays. You don't always have all the answers. Luckily now we had some of them. But when we started doing this thing, it was not the best scenario. So if you have the question on why didn't you do this or why didn't you do that? Well, probably we didn't think about it. Or if we did, there's no reason to understand why.

So just recapping real quick what I was mentioning. Now we had an issue with unmaintainability in our tests. That thing was not working well. And when I mean test, in this scenario, I'm talking about unit and integration tests. And that thing... Whoops. Okay. I'm not going to move again because it seems like it was when I moved. That thing was hard. Because I don't know if you're aware of what are the challenges on testing interactions with server state. But let's just recap real quick. Okay.

Let's figure out if something is going on. Do we got the signal back there? That's what I'm going to do. Okay. It's showing up again. So... Let's see. Okay. Woo! It's done.

So typically what happens when we're doing interactions and doing data fetching requests, we have the browser and the browser sends a request to the internet and the internet replies with the data. That's kind of what happens typically. So now we're going to... And I'm going to continue speaking while trying to figure it out because this thing is prepared. Now there's another scenario. So what you should be seeing here is an image on tests. So now on the scenario we have tests. And in our tests, we don't want this to happen. We don't want to actually go to the internet to get the data because that would mean we probably get different data every time. That would mean we would get flaky tests. And that would probably mean, once again, you wouldn't sleep well at night.

So me and my team had to figure out the best solutions to dealing with mocking data that come from server state. So we started with manual mocks in the beginning. We were using Jest, Jest FN, a bunch of manual mocking stuff. And it worked for a bit. But the more code we were adding, the worse it was getting. Because now we had to maintain a bunch of these things. And then we got to the other scenario. OK, let's add Axios mock adapter. Because we were using Axios as the client. So now we were maintaining manual mocks.

So now we were maintaining manual mocks. And we were maintaining Axios mocked adapter scenarios as well. And then I can swear, at certain point, there was even some sort of magic. Some witchcraft. I have no idea what that code still does to this day. I only know something. Every time I had to update manual mocks, the manual mocks would break Axios mock adapter. Every time I had to break, use, update Axios mock adapter, that thing would break the magic. And you guessed it. Every time we changed stuff in the magic, it broke the other thing. So this was the environment on writing tests every time we had to do them.

It was stressing. It was not working out for us. We wanted an ideal solution. We wanted something that worked better for us. And allowed us to get rid of all the things we had before. So in an ideal scenario, what if we could just have a solution that intercepted all the requests? One local place? We didn't have to do any setup on the testing environment? And by using a contract that we used to specify the API and the data that we were expecting for it, by using that thing, we were able to test our application and not worry. And this would be the ideal scenario. And really, that's what we have. But we didn't know what solution would fit us. And this was when we got to know about this thing called mock service worker.

So mock service worker, for those of you who are not aware, is an API mocking library that uses service workers, a ServiceWorker API, to intercept actual requests. So I know what some of you might be thinking. But wait, we're talking about testing, so that's probably in an old environment. Service workers only run in the browser. What are you talking about? We'll get into it a bit. But let's just recap how mock service works in a bit before we continue the story. So we already saw this thing. Usually, every time we need some data, the browser does a request, and the Internet returns us the data. Now, with mock service worker, there's something new.

There's a third user in this scenario. So there's a ServiceWorker right in the middle. So every time there's a request from the browser, the ServiceWorker is going to intercept that request. It's going to check the contract that you have defined within it, and by using that contract, it will decide which data to return. So pretty much, you can have a way to return mock data from there.

Now, some of you might be thinking, okay, but what happens on the scenario that we don't have a contract specified? Well, in this case, we just go to the Internet, we just let the browser do the normal request that it would do, and then get the data back, return it to the browser. And that's pretty much the gist of how mock service works.

Now, for us to understand a bit more on how this thing works, I'm just going to show you some fundamentals of this thing. So the first one are request handlers, and the second one are response resolvers. The request handlers are responsible for doing something, which is, well, pretty much specifying the contract, the API, and the route that you're going to hit. So let me just open this thing here. Oh, I don't want to draw. This happened last time. So let's try to get back here. So this is what happens when you try new stuff on stage. Let's see if I can get rid of it. Try it again. It's still there, but let's ignore it for a bit because I cannot seem to take it. So in this scenario, what's happening is we're importing the REST API. So pretty much we're saying, okay, we're going to have a REST API, and whenever you get a get request, pun not intended, I guess, to the route, Daniel GCFomes, you're going to return a response resolver. And that's pretty much the gist. So you're defining pretty much what protocol you're using, which type of scenario you're going to handle, in which route you're going to hit. But the fun part of Mock Service Worker is it also works with GraphQL. So you have REST. If you have a GraphQL scenario, you can import GraphQL, and you say, whenever there's a query for get users, you return this response resolver. So all of these that we have here, it's a request handler. What we have here is a response resolver. From the response resolver scenario, and let me take this part of here, the response resolver scenario, what you do pretty much there is specify the data that you're going to return whenever that route is hit. So whenever we have a GET request to the Neo4j CFoS, in this case, returning a response, which inside is going to return the JSON object, in this case, with the first name John, and the age 38. And that's pretty much the gist on how you can set up your own contract with Mock Service Worker.

Now this is where we get back to the part where I said, okay, this thing works in the test. Because while Service Workers run on the browser, Mock Service Worker also has a node intercepting package that allows you to run in node environments. And this is kind of how this thing works in tests.

So if you set up a worker, you can use a setup worker API to say, okay, I want to set up this service worker that's going to use this contract that I defined, and whenever the browser picks up, it's going to return the data. On the other scenario, you can say, now in another environment, I want to set up server, and this is going to listen for my test. So when my test triggers a request, that thing is going to return the data. So from an example that we have here, we are setting up a worker, so we are setting up a service worker with the request handler that we just saw. Every time there's a GET request to Daniel J. C. Afons, it's going to return the first name Daniel, last name Afons. And then what we do, we start the worker. And this is pretty much all the setup that you need to do in the browser to have mock service worker work.

Well, that was fun. Okay. So let's feature a scenario once again. There's a GET request to Daniel J. C. Afons. The service worker is going to intercept it. So what it's going to do, it's going to ask itself, do I have a defined request handler? And if so, it's going to return the data. And this is pretty much what we saw previously. In the scenario that it tries to get to a route that we don't have defined, like random, it's going to still ask itself, oh, I don't have something. So let's just go to the internet, let the request pass through and send it back. And this is pretty much what helped us save our tests. Because now there was only three steps that we had to follow to get rid of all that unmaintainability that we had. The first one is delete all the MOCs. Delete all the manual MOCs, all the access mock adopters. Delete all that magic, all the thing. It was the best part. I love deleting code.

Those poor requests are amazing. You just go there, like, oh, so much code deleted. It's so good.

Then we looked at the contracts, the contracts of the APIs that we were using, so we just went there, defined all the request handlers for our API and we start our server before our tests. And just like that, our unit and integration tests were working. They were not flaky because now there was just only one source of truth for the data that we were fetching, and this was pretty much me and my team afterwards because now we could rest for a bit and chill because now we could sleep at night. So we had to trust in the test we were building.

Now, remember, that was a third scenario, which is the task arriving late during the sprint, and mock service worker also fixed that funnily enough, so let's recap what was happening in my team. Now, usually, we had two-week sprints, and my team was comprised by backend developers and by frontend developers, and what happened usually when we were trying to build a new implement the respective screens for that was the backend took all this time working on a task. And I'm not criticizing here. Building an API is hard. There's so many stuff that you have to build. They couldn't speed it up enough. But this also meant that during the time that they were doing this thing, we had to do something else. We were building some unrelated smaller tasks, some more smaller tasks, and some more smaller tasks, until there was just this little thing here. And if you remember my intro, this was the time we had left to save the sprint. So it was that 2%. And this, like I said, caused the struggle. We were pointing fingers. We were like, we need to deliver this faster. The PM is all over us. We want to ship this faster to the users. I understand. We want to do our stuff as developers. It's our main goal. But when you have an environment like this, it's kind of stressing. And we can go now start talking about these functions of teams and agile processes and whatever. Probably you could have done that better. But this was a scenario where this piece of software fixed our issue. Why? Someone said, hey, look.

Mock service worker runs on the browser, right? It does. Cool. So what if we define a contract while we're starting the sprint? And someone said, okay. But why? What's the reason of that? Because hear me out. If we define a contract with all the team together, we can go into mock service worker and define the request resolvers. We could specify the contract. Yes. And then we can start this thing up on the browser. Yes. I'm following you. And then pretty much we're gonna have an API that's mocked for data. While the API is still not ready. So this means that while the back end is still working on the task, we can work on the task at the same time because now we have defined the contract and then we work against the mocked API. Once we finish, that thing is already in development or in QA environment, we turn it on against the right API and we test it. And it worked, it fixed that issue because now we were pairing work, we were shipping faster and we were not stress anymore. Then we had time to still work on the smaller tasks, but now we were not stressing at the end of the sprint to deliver stuff for yesterday. It made everything much better for us. And once again, we only had three steps to save our sprint. Define the contract at the beginning. Secondly, create all the request handlers and response resolvers. And finally, start the service worker. These three steps that worked on the testing also worked on the scenario now for fixing this dysfunction that me and my team had. Left us all celebrating at the end because it felt good.

Now we didn't have to argue at the end of each sprint. As I'm reaching the end of my talk, I want to share some love. Artem, the creator of mock service worker, has this great set of blog posts about mock service worker. Where he goes from all of the inception of what led to its creation, all of the challenges, and recently announced a course on that. I'm super excited to see how that thing is looking up. Just sharing some love, give Artem a follow because mock service worker is great.

On the last two minutes of my talk, I just want to take something home from here and remind you of something, which is, org-led engineers deliver amazing things for our users. Our users want these things for yesterday. They want them fast and they want them working. I feel like very often, and me and my team suffered through that a lot, we were getting stuck into this complexity loop. We were getting stuck into what's called solution engineering versus problem solving. We were getting stuck into the DIY, do it yourself, over engineering. We were stuck in all these tests because we said, oh, we're going to implement all these things by ourselves. What we didn't figure out there is we were losing time. We were losing time that we could be delivering stuff faster to our users. If we're losing time, we're wasting money of our company. So what I'm preaching here and I would like you to think about is, before you add into the DIY over engineering mode, think about something. Probably someone else out there in the world already had the same issue that you have, and probably they already went ahead and published an open source package. And probably that package is maintained, is tested, is secure, and it has even more scenarios than the things that you consider nowadays. So please consider that. Because we have so many great open source projects, we have so many open source maintainers here with us today. So give a look into those projects before you go into the DIY mode yourself. So if I had known 10 stack query before a couple of months earlier, probably, like I said, I would save much more money to my company and to my team. If I had known mock service worker before, I would have saved even more money. I would have saved me sleep hours, which, if you feel like me and you have a lot of insomnias, it makes it worse when your tests are not working. So yeah, these tools saved a bit of the way that I was building software. And they are my favorite. Pretty much every project that I build nowadays, I install them, because, well, they saved me so much time, saved me so much worries. And I really trust in everything that I need. And that was a fun fact in all of these things.

The fun fact that fixed all the issues that me and my team had at the end, was that all we needed was a contract.

So, thank you so much, React Advanced. I'll be now for the Q&A, right? I had a joke prepared. You had a joke. Yeah, and it's completely lost. It's completely lost. So probably even if I find it, it's not funny anymore. But great talk. Thanks for sharing.

Let's just jump into the audience. Let's see what people have to say. Yeah. Sorry, I'm looking at them there as well. So there's the funny ones there, but I can read them here, but I got a message from our wives. Oh, is everything okay? Okay. Just kidding. Just kidding.

What if the contract changes during the sprint? This happened to me last week. Question from Anonymous. Thank you, Anonymous. This is probably the most answered question every time I do this talk. And it's funny, because that happened to me as well. But I would say that usually the contract changes that happened are not going to be that many, hopefully, unless they go ahead and rewrite everything. But there's going to be some scenarios that you have some smaller contract changes. And when there are smaller contract changes, it's probably easier to go back, check for that specific scenario than for the entire contract. And at the end of the day, you still have to reiterate over the work you did, but it's not going to be all at the end of the sprint and having to deliver everything at the same time. So the bit that you're going to have to work is going to be a bit less compared with everything that you went before. I don't know if that answer the question, hopefully it did, but that's kind of the most common question that I get every time I do this presentation. Yeah. Nine out of 10 times, the contract won't change.

So you'll save time and that one out of 10 times, well... Yeah, great sum up. Yeah, that's the sum up. Yeah.

Another question from our active questioner, anonymous, how do you change the mock response per test so that you can test different scenarios in a test specification? Yeah. So that's one of the parts I had to cut because usually at the end of this talk I have a small demo, but well, we have 20 minutes. Pretty much you can define the entire contract, it has answers, it's request response, resolvers, and response. I forgot how to speak, sorry. Like Sara was just saying a couple of minutes ago, native is not my English not my native English, sorry, my brain just went on to answer this thing. Basically you can define the entire contract, but then for each specific test, you can go ahead, you can get access to the server instance that you're using, or in this case to the, yeah, to the server instance and you can say, okay, for this specific test, I want you to use this response resolver. And you can say only for this specific test, you override it. And then everything after that, that's just reset to the default. So pretty much you can customize specific scenarios for specific tests, which makes it a bit more simple than, for instance, setting up stuff like a mock server, if you had experiences of setting up mock servers, that's a huge pain, especially when scenarios like this, because then you have to go ahead and say, oh, okay, for this specific scenario, when I received this parameter, I want you to throw an error. With mock service worker, you don't need to just import the server that you're using to listen to everything and say, okay, for this specific test, I'm doing this and it just works out of the box. That's not a lot of setup that you need to do that. Awesome. Thanks.

Next question from Anonymous, how do you maintain the contract? Does mock service worker import Swagger, for example? Oh, that's a great question. I've been trying to see if that exists for a bit. I think it doesn't exist yet. So there's an opportunity, if any of you wants to try it out. I've been wanting to, but I haven't had the time yet. So usually what I've been doing is, the contract that I had in my team, usually when you build APIs, you either add most of it, or you can remove. But it's easy to remove. It's just go there and delete. And when there are small changes, you can go there in a specific scenario and just tweak it by hand. Obviously it would be ideal if we had something that could improve import from Swagger, like this example here. It would be really good, but to my knowledge, it still doesn't exist. I can question Artem, and I'll try to get back to this on Twitter or on LinkedIn, but it would be really, really good. Nice.

Right. I'll keep an eye on your Twitter then. The next person is using an express-based mock API and wants to know if there are any advantages to using or switching to MSW (Mock Service Worker). I was on my way here, chatting with some of the other speakers, and I was saying, I deleted one slide on why didn't I use a mock server instead? And someone is going to ask it. So here's the question, and I have the answers prepared for you.

So first, there are like five steps to this question. First, mock servers need configurations. You have to do a bunch of setting up the mock server, maintaining it, and configuring it to run on pipelines or wherever. For instance, if one of the tests fails and breaks the mock server, all the other tests will fail afterward. There are a bunch of disadvantages that you could name for these things. What I really like about using Mock Service Worker instead is that you don't have a lot of configuration. Once you have the contract, you don't have that much maintenance, and you don't have to worry about all the other scenarios. For instance, if we're using a mock server, we would have to go there and configure just a specific scenario. With Mock Service Worker, you just import whatever you add and say, 'For here, throw an error.' So you don't have to configure separate stuff aside. You can include this thing in your own solution because Mock Service Worker is around with your own projects. And the other better part is that you don't need to change configurations in your tests to point to the mock server every time you're running the test. You just start the server, and that's pretty much it with Mock Service Worker.

Next question is from Jack. How do you prevent just re-implementing the backend in your mock service worker, for example, to test the returning dynamic responses based on the parameters? That's a great question as well. For this scenario, most of the time, it's just a simple mock answer, some JSON or whatever, or some text transformations over the stuff that we had. If you need these dynamic answers, then for each specific test, you can just override it in that specific test. So if you're doing a test case on that desk, you can just say, 'Okay, here I want you to return this instead of returning that.' And that way, you avoid having to program dynamic answers on mocks on your contract, instead of having everything set up separately. So you mostly just pass the responsibility for the test that you're doing to give you the answer that you need, instead of adding all the other stuff on the request handlers.

So let me just really prevent just, okay. So for this scenario, most of the times I haven't had this experience. I haven't, most of the times it's just a simple mock cancer, um, just some Jason or whatever, or some exit transformations over the stuff that we had. If you need this dynamic answers, then for each specific test, you can just override it in that specific test. So if you're doing a test case on that desk, you can just say, okay, here I want you to return this instead of returning that. And that you in this way, you avoid having to program, having dynamic cancers on mocks on, on your contract, instead of having everything set up separately. So mostly pretty much just past the responsibility for the test that you're doing for giving you the answer that you need instead of adding all the other stuff on the, on the request handlers.

All right. Thanks, Jack. And thanks Daniel. First, next question is, are mock statically checked against the GraphQL schema? That's a great question. I don't know the answer to this one, to be honest, I haven't had a lot of experience with using these with GraphQL. I did some demos, but mostly the environments I've been working at rest based, I would suggest you to check the documentation because it's really, really good. And now they're going about just, they're about to release V2 of MS-Double. Some, some stuff might change. So yeah, my suggestion here is check the documentation and if you have a specific question, this specific question, you can just go on Twitter and tag Artem and we'll probably give you the feedback, right? As you need. So he's the source of truth for this. Maybe Lenz is still here. I don't know. Maybe he knows. He left already. He left us. But we'll figure it out. I'll also try to ask and I'll try to get back to the person who asked this, anonymous, I'll try to find this person. Good luck. Keep me up to date. Okay.

Oh, anonymous is another one. Can you define different mock servers with varying handlers for requests in example, based on different states of an application. Okay. So different mock with varying. Okay. So you want specific handlers depending on the scenario. Is that the, I'm trying to understand this question. So define different mock servers with various handlers for requests. Okay. So I'm assuming, and that's, I'm assuming if the person who asked here is here and you could clarify, I would love to, but I'm assuming that you want once again, dynamic scenarios, depending on what you have on your application. So once again, usually when you're doing a request, your request is going to go to a route and that route is defined with MS double. So imagine that you have a scenario that you want, you're going to the API A and that API is going to receive parameter B. So this is one scenario, but you also know that you'll have another contract specify that when it goes to the API A with parameter C, something is different. You can just in your request and would specify that specific route and they're probably, there's going to be different states is going to be different routes as well. Or you can just go the other way and just define that in your test. Well, I didn't understand this question so much, so I gave up a bit vague answers, but if the person who asked you this is here, please reach out to me, or if you're online as well, reach out to me and we'll try to figure it out together.

All right. Well, that's all the time we have for Q&A. So Daniel, thanks a lot for joining us here today. Thank you for having me. Now you're off the weekend. Enjoy.