stop, you're using GitHub Copilot wrong. In this video, I'll teach you how to effectively use GitHub Copilot so it becomes the number one asset in your toolkit and does exactly what you need it to do. So let's get into it. Here, I have a React project I've been working on. I'm currently in the process of converting from JavaScript to TypeScript, but it's sorely lacking tests. So let's try writing some tests and using GitHub Copilot to help us out. I want to make a test for the TextBanner.jsx. So let's go ahead and make a test file for it. Initially, GitHub Copilot has no clue what I want to do. So to help it out, what I'm going to do is I'm going to add a comment and say, Create a test for the TextBanner component. Great. Now it's getting started. It's going to import React, import Shallow from Enzyme, import the TextBanner. We do two lines because GitHub Copilot is trying to emulate common coding practices. Typically, you don't have functions or describes.

immediately after an import. So, sometimes it's necessary to do a little bit of extra line here to get the next output going. So, it's now described text Banner, and here we go. It generated a test. Let's make sure to close the parentheses, and let's take a look. So, this looks like a test. It's an enzyme test that's doing a shallow render and it's doing a snapshot test, but there's a problem with this. I am not using enzyme in my testing project. Let's go ahead and give this a run. Yarn test. And let's copy and let's get the test path for this and try to bring tests against it. And we're immediately going to get a failure because we're not using enzyme. And we can see right there, Load URL enzyme could not resolve enzyme. And if we look at our other tests, we can see that our other tests are using React Testing Library and not enzyme. So, why did Copilot choose to use enzyme versus React Testing Library? Let's get into a little bit of the

details with it copilot is trained off of the open AI codex. I went out there all it went through all the GitHub repos, looked at all the positive public repositories, and learned how to do testing. This is the correct test if we were using enzyme, but most of all the tests that it's ever been trained on most likely were enzyme tests. React testing library is fairly new versus the years that enzyme tests have existed, so by default it's guessing that we'd want to do an enzyme test because all the data it trained on probably reflected enzyme. If we went back, let's start from scratch and give GitHub copilot a little bit more context of what we want. Create a test from text Banner component using react testing Library. Let's prompt it of what we want to do next. We want to import react, and now it's getting going importing in our our dependency for testing Library. Import area text Banner subscribe block Empire setting up our code for a test, and we can see right here that we're doing render as fragment with a snapshot.

test so it's not exactly there. This is not exactly the test we're looking for either. Again, it's defaulting to the Codex, so it's not exactly sure how we do our tests. It's trying to determine based on what it was trained on. There are a couple issues in here. One is the actual import of our text Banner. We're not using default imports; text Banner is a named import. And also, we're not doing a good formatted test and not properly testing our component with props. If we open up test Banner, we can see that it's a named import, and we see we should at least be receiving text in order to display well. In order to help GitHub co-pilot along so it can more effectively test our component, we need it to be a bit more context instead of just relying on the Codex model. If we open up our text Banner component kitakopa is able to read our code and get more context of what our code is actually doing, and so it can more effectively write a

test that matches what our component is actually expecting. So now that our text Banner is open, let's go back and just delete the test part. Let's also delete the import. Now let's try importing again, and now it knows to use a named import because it's now reading the context of our text Banner. Let's keep on going. Describe text Banner, and now it's doing it block. Let's take a look at what it outputted. So, renders a text Banner. Text Banner hello world. Get by text. Get by text hello world to be in the document. This look, this is actually looking pretty good. Let's click save and see what our test Runner does. Okay, we got a passing test. Nice. So looking back again, we can see that it did the named import. It also passed in the prop properly for text hello world and did the assertion on hello world. So how might we be able to help GitHub co-pilot write tests more easily for us without us having to prompt it to actually use react testing Library or just like we did with opening up the

component so we can get better context on how the component is used. If we opened up a neighboring test, it can scan that test and understand how we are writing other tests. So when we start generating code, it's inspired by the other neighboring tests and how that code is written and starts generating code similarly. Now that we have another test file open, let's go back and let's try generating tests again. Let's start from scratch. So we're going back to just create a test for a text Banner component. New line, let's import react. And now we can see that it's suggesting react testing Library. Just keep on going with this. Ooh, but now it's interesting. Now it's guessing the uwp theme. Interesting. And that's because it's using the context from the previous test. And you can see that in our previous tests, we're also doing an import. So it's kind of guessing, hey, this is what you probably want to do. But that's not the case. So we can just keep on going. So we'll just skip that line and let it

prompt us to the next thing so import text. Banner that looks correct. That's what we want. Let's do a new line. Describe and there's part gonna generate us our test. Nice. So now we can see. Describe text. Banner render successfully. Query by text. Render text. Banner. Hello world. Query by text. Everything's looking solid. Let's go ahead and save that again and see what our test run outputs and we have a passing test. Maybe you don't believe me that you need to open up neighboring tests in order to humble it along and understand how you write tests in your project. So to prove that to you let's go ahead and close the test file so no longer is it scanning any tests and then let's delete everything all the way up to our prompt and let's click enter and see what happens. Input react and then now it's suggesting to do enzyme again. See so copilot needs help from you in order for it to do its job. If not it's going to default to using the Codex model so

the more files that you have open that are related to the code you're making, the more information you give GitHub co-pilot in order for it to effectively help you out. So open up the files you're working on so GitHub co-pilot can help you implement what you need to be done because it knows exactly how your project is built. And if you like this video, please hit that subscribe button and let me know if you'd like to see more content. I'll catch you in the next one. Peace. [Music]

GitHub Copilot: Tips and Tricks for Better Productivity

Talk2MeGooseman is a Ruby on Rails full-stack developer, Microsoft MVP, Twitch Stream, and Twitch extension developer.

You can watch Talk2MeGooseman Twitch live streams at https://twitch.tv./talk2megooseman.
You can follow Talk2MeGooseman on Twitter @Talk2MeGooseman.

GitHub Copilot: Tips and Tricks for Better Productivity

GitHub Copilot: Tips and Tricks for Better Productivity

스크립트