TestJS Summit

TestJS Summit 2022

Testing is hard, testing takes time to learn and to write, and time is money. As developers we want to test. We know we should but we don't have time. So how can we get more developers to do testing? We can create better tools.Let me introduce you to Playwright - Reliable end-to-end cross browser testing for modern web apps, by Microsoft and fully open source. Playwright's codegen generates tests for you in JavaScript, TypeScript, Dot Net, Java or Python. Now you really have no excuses. It's time to play your tests wright. by <a href="https://www.froala.com/wysiwyg-editor?pb=1"> </a>

Testing Web Applications with Playwright

Debbie O'Brien

React Advanced

React Advanced Conference 2021

Let's face it React is a way of building component driven applications. So technically we are all doing component driven development. But are we. Are our components really isolated, composed and tested in isolation or are they still coupled together just a little bit!! Let's take a look at how you can really be component driven so you can build, scale and reuse React components across all your React applications. <a href="https://www.froala.com/wysiwyg-editor?pb=1"> </a>

Taking Component Driven One Step Further

♪♪ Taking component-driven one step further. Hey, everyone. My name is Debbie O'Brien. I am Head Developer Advocate at Bit. I'm also a GitHub star, a Microsoft MVP, Google Developer Expert, and Media Developer Expert. And you can follow me on Twitter at debs underscore O'Brien. So let's get started. How it's going? And oops, I completely stole Matt Billman, the CEO of Netlify. I stole his slides from his keynote talk. Sorry, Matt. What he said is, how it's going. Number one, he said monoliths are moving to APIs. Number two, Git has transformed the web. Number three, components. Number four, pre-building in JS. And what I want you to focus on is number three, thinking in components. And as he said, the world is moving towards a component-driven world. We're moving towards a component-driven web, and we really need to all be thinking and working in components. Now, you might already be saying, but I'm building in React, and you're totally right. React was built for component-driven development. React was built for components. And basically, what we're doing is, we're building in components. So yes, if you're already building in React, you're doing a great job. We are now building component-driven development applications with React. Cool. So what's the problem? This is our application. It's amazing. This is my beautiful shoe store, and I have made this application out of components. So that button component is actually only one component that's reused inside that hero component in the theme toggler at the top and also in the product card. So we're building in components, and this is how we are building nowadays. And this is great. This is fantastic. The problem is that the components have no value outside the app. So once I've built that application, all those components, they're kind of stuck inside that application. Now, that's a problem. That's not really making component first. You know what happens when we have to build multiple applications? Along comes the product manager, says, we need to build another app. What do we do now? We've got this amazing application and all these components. What do we do? So we've got now three applications, and a lot of these components are similar. We're building similar e-commerce applications. So we've got big components like that shopping cart. How do I rebuild that whole component again and again? I mean, yeah, just a simple button, copy, paste it, put it in there, be fine. Or will it? There'll be inconsistency across all your applications eventually, especially if you scale and grow and grow and grow. So really, you need another solution. You basically want to be able to easily share those components across those applications. And there are a couple of options out there, of course. And you could just basically package them up to NPM and hope for the best. I mean, there's a lot of work involved in that. It is possible, but it's painful. And we don't want pain, right? So there's a couple of options, as I said. And one of them is to work in monorepos. Now, a lot of people do this. A lot of people are very happy working in monorepos because it allows you to scale those applications, put loads of applications inside the one repo. And when you do that, you can improve velocity. So you can just build more and more applications really easily because you have access to all the code from each of those applications. That means you can do code sharing really easily and reuse any of those components in any of the applications. So the dev experience is actually pretty good, right, because you have access to everything. So it's easy for you to just, you know, build stuff from anything that's in that repo. And if you have to refactor any of those components, well, it's kind of pretty easy, too, because, like I said, you've got access to them. And cross-team collaboration, you're working with all the team members on this. So, you know, it's pretty good. And you've got some standardization going on because you've just got one repo to maintain. So everything's running on the same standardization. So this is a good point. Unfortunately, with monorepos, there are a couple of issues. The tooling wasn't built for monorepos, so the tooling really isn't there. Your IDE can get slow because you've got so much code to load. And, you know, you've got, like, git pull, git push. Again, it's going to be quite slow because you've got so much to pull down. When your teams are getting bigger and bigger and bigger and more people are making changes to that main branch, you've got all those, like, merge conflicts to deal with, and you're constantly, like, bringing those new changes in. Visibility and discoverability, this can kind of go both ways, right? Because you could say, oh, in a monorepo, I can actually see all those components that are available to me. And you can. You can see all the code. But you can't really see what the component looks like. You'd have to, like, which app is it being used in, and you'd have to try and find that application to see what it looks like to try and kind of really discover and visualize it. And you've got, like, to make gradual API changes because if you start modifying the API, you don't even know what component is using that API. So that component is being used by another one. Is it being used by what application? So it's really hard for you to see where it's being used. And are you going to break someone else by just, like, modifying the props, modifying the API of that component? Probably. That's not good. Onboarding developers can be, you know, pretty hard. You get a new developer in, and you give them this massive code base and say, good luck, go swimming, find the code, figure it out. You know, what if you could just separate it out so that one new developer just has to worry about the code that they have to worry about? That'd be much better, right? And the feedback loop, it can go on for quite a while because it's got to go through such a process. And when it finally makes it to production after everyone else has finished building what they're building and maybe you deploy at this time at a specific day, you know, once it gets deployed, so there's a long wait time when really you just want to, you know, make one change and just deploy it, right? Why can't we do that? Team boundaries and ownership. I mean, there are no boundaries, right? Everyone's working in the one code base. I mean, you could say, don't touch that folder that belongs to that team, but that's kind of, like, pretty hard, right? There's no policing that. So there is no real boundaries. And your build times can be pretty big because you've got to build not just that one application, but every single application in that monorepo and all those components. So, you know, do people actually like working with monorepos? Do they hate them? Do they love them? This is what I asked. And you know what? The problem is actually the tooling. The problem isn't the monorepo. Monorepos is a great way of thinking of doing stuff, but the tooling just hasn't helped, as Oliver says, or Garrett says, crappy tooling. Even Brandon, he's like, loves the fact that you can share code between apps and libraries, visibility, collaboration, consistency, ability to standardize single package versions, but he hates the insufficient tooling. This is what makes the experience bad, leads to bloated CI, and just loads of ad hoc scripts. So how can we fix this? How can we make this better? You know, what do people want? That's what we got to look at. What problem are we trying to solve here? What people want is the ability to share components. They want to be able to easily package, manage their components. They don't want to have any version conflicts or break each other. They want to have quicker build times. They want to just build what they're building and like have that released and not have to worry about what everyone else is doing. They want team boundaries and ownership. So they want to own their own feature, their own components, and like just work on those and leave everything else as if it like doesn't exist. And they want consistent tooling. They want all those components to be built with a similar kind of tooling so that they're all going to, you know, build as they should be built and look the same across all those applications. And they kind of really, really want simple decoupled code bases. So they only have to worry about the code that they're actually going to have to worry about. So we're not asking for a lot, are we? Well, actually, welcome to Bit. Bit is a tool for component-driven development. And with Bit, a lot of these problems are solved because of how Bit allows you to work with components. If you want to work in a monorepo, you can work in a monorepo with Bit. You can simply have your base UI components, e-commerce components, and your store components, your application components, all in the one monorepo. The difference is that every component is completely isolated and versioned. And therefore it's like its own little kind of repo, I guess. Every component is isolated, which means it can be used in any of those applications or any of those other libraries. Now you can also have a simple decoupled code base. So you can literally say, okay, I'm going to separate it out because you know you're scaling, team's getting bigger, and you want teams to own features. So you can have one team, base UI, this is your repo, and these are your components. You're in charge of this and build your components and deploy your components when you want to. E-commerce team, here's your components, build your components, deploy your components, and just work wherever and whenever you want to. And then your applications, there could be another team that own the specific applications and they can deploy their components and their application whenever they want to. As Bit versions each component and isolates each component, it can then be used in any of those repos, installed into any of those, and basically used across any repo. So here's an example. This is my base UI code base and VS code. And you can see on line two, I'm importing the button as a component from this actual repo, right? From the base UI repo. So it's importing it instead of using a local import because every component is version and isolated. I need to basically install it as if it's its own package. So I'm installing this button and using it inside this team toggler component. Now my e-commerce team, I'm installing the button as a component. And I'm using it inside of my team to install the button as a component. Now my e-commerce application, or actually this is not an application, it's just a load of e-commerce components. But in this e-commerce repo, I'm actually installing that same button component. So here I'm installing the base UI from the base UI repo, the button, the card, the heading, and a few others are coming from a different repo, the one I just showed you. And it's also installing some components from this particular repo, from the e-commerce repo. So I'm installing the button component and I'm installing the button component. And I'm installing the button component and I'm installing the button component. And I'm installing the button component. And I'm installing the button component. And I'm installing the button component. And I'm installing the button component. And I'm installing the button component. And I'm installing the button component. And I'm installing the button component. And I'm installing the button component. And I'm installing the button component. And I'm installing the button component. And I'm installing the button component. And I'm installing the button component. And I'm installing the button component. And I'm installing the button component. And I'm installing the button component. And I'm installing the button component. And I'm installing the button component. And I'm installing the button component. And I'm installing the button component. And I'm installing the button component. And I'm installing the button component. And I'm installing the button component. And I'm installing the button component. And I'm installing the button component. And I'm installing the button component. And I'm installing the button component. And I'm installing the button component. And I'm installing the button component. And I'm installing the button component. And I'm installing the button component. And I'm installing the button component. And I'm installing the button component. And I'm installing the button component. And I'm installing the button component. And I'm installing the button component. And I'm installing the button component. And I'm installing the button component. And I'm installing the button component. And I'm installing the button component. And I'm installing the button component. And I'm installing the button component. And I'm installing the button component. And I'm installing the button component. And I'm installing the button component. And I'm installing the button component. And I'm installing the button component. And I'm installing the button component. And I'm installing the button component. And I'm installing the button component. And I'm installing the button component. And I'm installing the button component. And I'm installing the button component. And I'm installing the button component. And I'm installing the button component. And I'm installing the button component. And I'm installing the button component. And I'm installing the button component. And I'm installing the button component. And I'm installing the button component. And I'm installing the button component. And I'm installing the button component. And I'm installing the button component. And I'm installing the button component. And I'm installing the button component. And I'm installing the button component. And I'm installing the button component. And I'm installing the button component. And I'm installing the button component. And I'm installing the button component. And I'm installing the button component. And I'm installing the button component. And I'm installing the button component. And I'm installing the button component. And I'm installing the button component. And I'm installing the button component. And I'm installing the button component. And I'm installing the button component. And I'm installing the button component. And I'm installing the button component. And I'm installing the button component. And I'm installing the button component. And I'm installing the button component. And I'm installing the button component. And I'm installing the button component. And I'm installing the button component. And I'm installing the button component. And I'm installing the button component. And I'm installing the button component. And I'm installing the button component. And I'm installing the button component. And I'm installing the button component. And I'm installing the button component. And I'm installing the button component. And I'm installing the button component. And I'm installing the button component. And I'm installing the button component. And I'm installing the button component. And I'm installing the button component. And I'm installing the button component. And I'm installing the button component. So, here we've got our product card and we have the latest version. It's version 1.0.13. And basically we can go back in time at any moment. And we can see the state of that component. 1 back or 10 back or 0, 0, whatever. And we can see what it would look like, what has changed. And we can decide what version of the component we want to use. Now, if we're working in a workspace and we were to modify the price component, for example, of the product card. Then the product card will get auto-tagged and a new version will auto be created. Because the price component that it depends on got modified. Now, if you're working in another application, in another wrapper, and that product card gets a new version. You're not going to break your app or anything. Because you get to decide if you want to use the latest version or not. Basically, it will tell you there's a new version. Do you want to import the new version? And you can say, actually, no, I'm not ready to update this version. Because you haven't finished updating the rest of the application to the new theming or etc., etc. So, you always get to choose which version you want, when you want to update. And you can have multiple versions, different versions across different applications, if that's what you want. And you can see what's going on at all times. So, you can look at your component and you can see this product card component is using version 2.0.1 of the button. And you can see it's using the card, the heading, the image, the text, the available colors, and the currency component. And which version all of them are on. So, at all times, you can actually visualize the dependency graph of your component. So, basically, we want to reuse components in any app. This is what we're trying to achieve. We want to take the components out of the app. And we want to make the components isolated. We want to make the components their own specific, like, they want to basically say, you're a component and you live wherever you want. At the moment, you're going to live in the base UI repo, in the e-commerce repo, whatever. But that's not important. What's important is that you are isolated and versioned independently. You can be released independently. And you can be installed into any application, any other component, whatever. You can be used at all times very, very easily. And this is what you want. You want to make the component number one. This is what we call component-driven. And this is basically what we all should be doing. We should be building component-driven webs, component-driven apps, component-driven everything. And building with Bit is going to make that easier. So, I highly encourage you to check out Bit, give it a try, and start thinking in components, building in components, and building a better web. Thank you very much, everyone. If you want to see the Bit demos that I walked through in the shoe store, et cetera, you can just go to bit.dev slash learn-bit.react. And you'll be able to see all those that I just showed you. Or you can just go to github.com slash bit-demos. And you'll see all those individual repos. And you'll see how the components are being used across all those repos. Check out our docs for more information. There's videos and there's all sorts of stuff on there. And, of course, you can follow me on Twitter, devs underscore o'brien. If you have any questions at all, if you want to play with Bit a bit more, and you've got some feedback for us, DMs are always open. So, yeah, have fun building components, building React applications, and making the components number one. And the components are just going to be used within all those applications wherever, as many as they want, wherever they are. And that's it. Thank you very much. Bye. ♪♪♪
