Chris Harbert: Test-driven Development, AI, Pair Programming, Agile Testing

In this talk, Chris discusses leveraging AI as a pair programmer to enhance software quality while practicing test-driven development (TDD). He compares traditional pair programming, where two developers work collaboratively with one another, to the integration of AI tools that assist in coding tasks. Chris emphasizes the significant benefits of TDD, such as improved code quality, reduction of bugs, and better knowledge sharing. He explores the live coding of a bowling game kata, focusing on implementing features step-by-step and utilizing AI to suggest code solutions. Throughout the session, Chris highlights the importance of maintaining an active role in decision-making while using AI and the potential challenges faced, such as inconsistent results from AI. The talk aims to inspire developers to incorporate AI tools into their coding practices and enhance their overall development experience.

Um, it's my pleasure to introduce Chris. Um, I've known Chris for, wow, it must be several years now. We went to several testing conferences together. Um, we met in Rally North Carolina for the first time. Uh, we're both passionate about quality. And Chris, as you know, did the keynote and, uh, talked about how AI is dangerous and how we should be have a movement to really make

sure we're not letting AI run wild. So he asked me to say it's ironic this talk is going to be about how can we use AI to help improve quality as opposed to being uh you know negative. So AI as your pair programmer um just to say Chris is an industry executive international conference speaker host of the developers who test podcast and founder and CEO of Tastery

a company that helps teams uh ranging from startups to Fortune 500 companies increase test coverage and improve their CI/CD processes. A big round of welcome for Chris. [applause] >> All right. Hello everyone. Uh I'm glad the room isn't empty because that means I didn't completely bomb it this morning. I was a little worried. And I'm also glad that you're coming to a talk about how to use

AI as your pair programmer from the same guy who just told you all of the dangers and hazards of overrelying on AI. Because part of why I think this is so important is we took a leap. So when I first learned how to do test-driven development and pair programming in the mid-200s, uh we spent the first week with all new employees learning how to do test-driven development,

why we should do test first. And we put a lot of discipline into how to write code. And now that we're leveraging AI to do things, it's way too easy to just say, "Hey AI, I want to purchase path build everything." So we've zoomed all the way out where even just six months ago, we wanted to look at how do we write tests for an individual class

or object or process. And so this is going to be about taking the lessons we learned from test-driven development and how to treat AI as your pair programmer while doing testdriven development. I'm also going to do a few things that you shouldn't do. Uh, one of them is have a keynote backtoback with a presentation. Uh, the other one is, uh, I'm going to be doing a lot

of live coding examples um, using AI and so we don't know what's going to happen. And part of why I want to do that is it's way too easy to just show you the successful examples. So people will say, "Hey, I did this amazing thing with AI. I did it in one day." And they won't show you that it took them seven days to figure out how

to do it in one day. So we're going to do this live. I've practiced it a few times. I got good results. But is Claude going to ship a new version today and I'm going to try it and get a completely different result? We don't know. So there's a little bit of excitement for all of us here uh when we get into that part. And then the

other thing I've been told is when you go to a software testing conference, a lot of the people in the room don't know how to write code and so you shouldn't show as much code at a software testing conference. Uh we're going to break that rule too because I think that's something that is changing very quickly. Uh we're seeing more and more people engage with writing code

and it's more accessible than it's ever been. Uh so hopefully you don't check out too much or get bored and you're in it for the ride. and we have a little bit of fun today. Okay, skip the agenda. Oh, and I need to press start on my timer, so I might be a few minutes behind. Uh, pair programming. So, as I said, I learned how to do

pair programming at a company that was doing extreme programming with test-driven development. And to give you an idea of what this was like, uh, we actually had, uh, two developers working on one computer with two monitors, two keyboards, two mice. And so you would be sitting here and I would be sitting here. And we would take turns being the tester and being the developer. So one person

would write the test, the next person would write the code to get the test to pass. And we might trade off who we're paired with throughout the day. We might trade off who's the tester, who's the developer, but it was an extremely disciplined way of building software. And it's one that we can replicate with AI today. So in traditional pair programming, um there's a few different ways

of, you know, is a tester, developer, is it driver, navigator. Um, you have one person write the code, focus on implementation, and you can have the other person who's reviewing the code, thinking strategically about what the code is supposed to do, spotting potential issues, and suggesting improvements. How many of you work at companies that ask you to do a code review, like have poll request, code reviews?

Do you think that would be necessary if every line of code was written by two people, where one person's writing the test and one person's writing the code? And do you think it would be more effective if the person doing your code review is actually watching you write the code while you're writing it in the modules and say, "Hey, you forgot this test. You forgot that test."

It's incredibly effective and there's a lot of benefits that you don't see when you do it that way. Um, you know, one is I can go take a vacation and there's always somebody else who's familiar with the code. Today it can be hard to take a vacation uh you know you've been assigned one task, you're the only one who knows it. Now you get called up when

you're on vacation and you have to come fix it. And that's not true if you're doing pair programming and test-driven development. So why don't we all do pair programming and test-driven development today if it's something we came up with in the mid 2000s and it produced incredibly good results? One of the big reasons is management said,"Well, if there's two people in one computer, I'm getting half the

work, but I'm paying twice as much." Which isn't true, by the way, but it's very easy for a manager to look at the situation and say, "If there's only one computer, I'm not getting as much out of the two people." So, what's interesting is when we Oh, yeah. So, I talked about benefits. Sorry. High code quality knowledge sharing, problem solving, and fewer bugs. But some of the

challenges with pair programming when it's done traditionally is one is scheduling conflicts. So the company I worked for there were four pair programming sessions a day. Each one was an hour and 20 minutes and you were sitting next to the person and then you had a scheduled break. Uh that quickly fell apart when people went to a remote world where you might be on one workstation, I'm

on the other one. I'm getting up in like right now I'm eight or nine hours ahead of my home time zone. If I'm pairing with programming with somebody, I'm up at midnight and they're just getting home from school or work. Uh so the time doesn't work. Uh there can be personality clashes. Um you know, we had conversations like how do you pair program with someone if they

smell bad? [laughter] I mean, you're sitting like on one computer next to this person. if they talk too much, if they like one person like would bite nails and like trim nails and they'd fall into the keyboard. And we we had shared keyboards, so like we're switching stations. And so like some people they would like unplug the keyboard, bring their own keyboard with them to plug it

in. Uh so there's definitely a lot of personality clashes when you're doing traditional pair Uh and then skill imbalances. So one person can dominate the conversation. That's actually a benefit if they're helpful. So if you have somebody who's knowledgeable pair with somebody who's not knowledgeable, it's an amazing way of knowledge transfer. But you can also have somebody who checks out because they're not comfortable with their own

skill level. And at that point, they're just sitting there watching somebody else do the work and that's not the intention of their programming. Uh so that can be a challenge. And then it's also just tiring to be pairing with somebody for six hours a day. So uh and then uh I don't think it's on the slide but the management perception of getting half the work was one

of the big challenges. Oh yeah cost two developers one All right. So in test driven development to give you some background on it the way it works is red green refactor. So you start out with red where you write a failing test. green where you make it pass using the least amount of code. Uh we had a saying do the simplest thing that could possibly work. Uh

and then you refactor the code to improve the design of the code. And when you refactor the rules are you're not adding functionality, you're not getting tests to pass, you're starting with green tests, you're improving the design of the code, and you're ending with green tests. So in a a simple calculator example, uh you might write a failing test and uh you would say I should be

able to add two numbers uh and I expect when I add two and three that the answer should be five. Then to make the test pass, you could return. And actually the simplest thing that could possibly work, you could debate some people would actually in this case return five because that's going to actually pass the tests. And that that sounds silly, right? Like you know a calculator

shouldn't just return five. But what that's telling you is 2 + 3 equals 5 is inadequate for testing because you kind of know I need to do more than return five. So you had another test that says, "Okay, well 0 plus 5 is also five." And so now that you have two tests, now you need to update the code. And that's where you get into the A

plus B. That's an overly simplified example, but when you do that with a calculator, now think of a password validator. What's a valid password? What's an invalid password? Your first test is going to say like Bob is an invalid password. Your second test is going to help you understand why Bob is is an invalid password as you're adding tests. Uh and then you refactor. And refactoring is

is very important. Uh because test-driven development when done properly with refactoring actually results in very well-designed code because it's code that's testable. It's the simplest code that actually meets the requirements. uh and refactoring gives you an opportunity to say okay as the as I add tests you're basically adding requirements to a system right so you're getting the feel of what it's like to modify this system as

new requirements come in and that's really important so I want you to think about that uh if I'm adding new requirements as the system comes in and I'm seeing that that's difficult what's it going to be like 3 months from now when I'm not familiar with the codebase and I need to come in and add new functionality. So refactoring is an opportunity to say, hey, it was

kind of difficult to update this calculator function to handle subtraction. Maybe I should clean up the code while I'm in here because tomorrow I might have to do division or tomorrow I might have to do uh exponents. Uh benefits of doing this, it forces you to think about things. Uh you get living documentation. I'm a big fan of and this was preAI being a big fan of

tests being a form of executable specification. So they are the documentation for your system that you can actually run to confirm that your system works properly. build things, what's more important than having documentation that you can execute to confirm that the system does what it's supposed to, this gives you confidence. It makes it safe to refactor and change the code. And it also gives you fast feedback

so that you know immediately when something's broken and you can focus on only what you need to focus on. You don't have to be familiar with the entire system. And as a developer, when I came into this this new company, the very first day, they have you pair with someone and they had you ship something all the way to production. And it didn't matter if you were

an intern, it didn't matter if you just graduated from school or if you were a developer with 10 years of experience. You come into this environment, you pair with somebody, you And if you've ever worked in a system that doesn't have tests, you become very paranoid. You're like, if I change this, what are all of the things I need to think about? I'm afraid to make changes.

Now, if you come into a system where, you know, all of the tests are bulletproof. I've got unit tests, integration tests, I've got end to end everything is is well documented in the form of an executable specification. Then when you go into this calculator and you can say, I have no idea how the calculator code works. I don't know if they've already implemented uh multiplication or division.

and I'm just here to do exponents. But now I can see that there's a calculator test class. I can add my test to it. And if I break something with division, I'll find out right away. So now instead of being a paranoid developer, uh you're an empowered developer who can go and make changes. But there are also some challenges. Uh development properly has a bit of a

learning curve. uh there's a time investment. So it might feel like it's slower initially. Uh you know, hey, but I could just add this thing to the page. Why do I need to add a test that goes to the page to see if the thing's on the page? That's twice as much work. Are all of our projects going to take twice as long? Uh you have to

maintain a test. So you can't just create the test and forget about it. And by the way, it's not a flaky test if you change the code and don't change the test and then there's a test failing. Uh so I think that's in my flaky test presentation as like kind of a pseudo flaky test. Uh but a test is really just detecting a change. It's up to

the person to determine whether or not that change is a change that you want or a change that you don't want. Uh but a test is just a well-designed test is going to tell you that something changed and it should communicate what the requirement was and then you can make the decision is that a requirement we wanted to change or not and then also just getting started

like what do I test first? Uh this is especially true if you're dealing with a legacy system with millions of lines of code. Uh older code that maybe didn't have testing frameworks very well supported when the code was originally written. Uh it can just be a challenge to know what to test. And so now we're going to introduce this concept of AI as your pair programmer which

hopefully is combining the best of both worlds instead of the worst of both worlds. Uh so now in this case you're still directing the solution, making decisions, understanding the domain, testing the results and AI is available 247. Um so unlike the pair programmer who uh might be on a different time zone or might be a slacker and only work three hours a day, uh AI is there

for you whenever you want to work. It can suggest approaches to how to do things. Uh it can help write boilerplate code. Um if any of you have ever had to open a file in Java, there's a lot more lines to open a file in Java than you should really have to know. Uh with AI, you just say open a file and it says, "Oh, this is

a Java project." Boom. Uh it can help you spot patterns and it can help you explain concepts. And the reason why this works well is we heard in an earlier talk about the context window being important with AI. Uh the context window is like AI's memory. And as you're doing a lot of things and as the conversation's getting longer, it starts to forget what happened at the

beginning of the conversation. And as your code base gets larger, the context is huge. And companies are constantly increasing the size of their context. And so it's becoming less of an issue, but there's always going to be some amount of context you want, even if it's what features did we build three years ago. And so test-driven development is a way where you can say, hey, this is

the part of the system that we want to focus on and change. You still get the immediate feedback. Uh, and that's important because AI is going to try to do things as we'll see where its first guess will not work. and it might have made a reasonable guess. But you know, one example of a guess that wouldn't work is if you've ever tried to implement something with

Spring Boot, there's some terrible documentation online about here's how you do X, Y, or Z with Spring Boot. Uh, and you go and you try it and it doesn't work. So sometimes the information AI is learning from is wrong. And developers who've used that documentation have the same problem. So why would we expect AI to not have that problem all of a sudden? Uh there's also the

versioning problem. So maybe it learned how to do Spring Boot from this website that was this version of Spring Boot. But now when you say I want to add OOTH, it goes to this other website that's showing a different version of the same libraries. So yes, both information sources are correct. But when you put them together, it's going to try to run the code. and now all

of a sudden you can't log in because the library it's calling doesn't exist. So there are all these problems that are going to happen when AI is trying to write code. And the best way to get the immediate feedback is to also have the tests written first. So then when you try to log into that website and AI pulls these two sources together, gives you a very

good starting point, it's going to say, "Oh, wait. I have a failing test. Let's go fix that." Uh there's also iterative improvement which is good for test-driven development and it's an op learning opportunity and if you haven't tried uh I highly recommend going out and downloading one of the the AI tools. We're going to look at clog code today. Um I don't have a partnership with them

or anything. Uh but we're going to look at clog code and you can point it at any repository. You can point it at your company's repository if they're okay with it and you can just start asking questions like how do I add this type of new feature. You don't have to necessarily have it add the feature. You just ask it how do I add this feature? Uh

and it'll explain what it thinks you can do and that way you can actually learn about your own codebase. Uh but this is a huge opportunity to also learn about other people's code bases that are published online. So there are a lot of public repositories where people give examples of how do you do playright testing, how do you do selenium testing uh open-source libraries for doing x

y or z and you want to know okay if I'm like spring for example if I want to know how authentication works in spring I can point AI at spring's open source code and say how does authentication work and I can ask it questions about well what kind of controller do I need and it's going to actually look at the source code for the open source library

and give you pretty good suggestions of how to work with their library. So, it's almost like having a form of documentation that they've given you that they didn't have to spend the time to write in order to give you that Uh so, definitely a learning opportunity um when you're doing this. And then cloud code in particular, it can access the file system. That that's a risk but

also an advantage. Uh it can run the test directly, which we're going to see it do. uh it can help refactor um so you can say I want to do certain types of refactors uh safely maybe I said safely but maybe that's why we test uh and then context awareness um so it has some nice functionality for managing the context and then it also knows some best

practices and patterns so now we get into how do we do this in real life and the company I mentioned when we did our week-long training. One of the examples we went through was the bowling game. And I had to ask people before I came, does everybody know about bowling? And I got different answers. uh I don't know, show of hands, does anybody not know what bowling

is? And you don't have to worry, but bowling's pretty well known. All right. Either it's well known or or uh people don't want to admit they don't know about bowling. Uh but in the US it's a pretty popular pastime where uh you roll the ball down the lane, you try to knock down 10 pins, you get a higher score the more pins you knock down. And a

kata is this idea of if you want to get good at something, you have to practice getting to perfect form. And so the bowling game kata is a challenge for programmers to practice getting perfect form with their coding exercises. It's a good way to learn and you can even do this in a session where you have you know two people pair programming in front of a crowd

uh small crowd of like your teammates um depending on what people are comfortable with and then people can say well why'd you do it this way why'd you do it that way and it's a really amazing way to learn how to write good quality software and so we're going to attempt to do that today um we're going to do the bowling game Kado with AI so getting

into the the examples of bowling. Uh here are the rules. There are 10 frames per game. Uh normally under normal conditions, there are two rolls per frame. So I get two tries to knock down all 10 pins. If I do knock down all 10 pins, that's what's called a strike. If I knock down all 10 pens after two rolls, that's called a spare. And then there are

typically 10 frames. And in the 10th frame, there are some special rules for what do we do in the cases of strikes or spares. Uh I think that kind of reiterates it a bit. Um but in the case of a strike, if you knock down all 10 pins on the first roll, the score for a strike is 10 points for the 10 pens you knock down. And

then you also add the next two rolls as a bonus to that frame. And then for a spare, you've knocked down all 10 pens in two rolls, and you only get to add the next roll to the Hopefully, this will make sense when we start adding them up. Uh, so here's a sample game. In the first frame, I roll a strike. So, I got 10 points for

knocking down all 10 pins. In the second frame, I roll a three and a four. So, I get seven points for that frame. And then retroactively, I go back and I add the seven points to the first frame. Uh frame three, I also got a spare. So now I only get to add the five to frame three. Um so I don't get to add both rolls, uh

just the five. And this provides a good example for test-driven development because there's some quirkiness in the rules of the game. And as you're adding layers to it, it causes you to change what you've written in terms of code. Uh, and then the key points, strikes and spares, uh, get bonus points. Bonuses come from your future rolls. And a perfect game would be actually getting 12 strikes.

So, you do you knock down all 10 pins for all 10 frames and then you get two bonus rolls added to the end. Uh, and that totals up to 300 So, that summarizes what we just said in terms of scoring. So, we're going to set this up from scratch. We're going to start with the simplest test case. We're going to hopefully build incrementally using test-driven development, add

on how we do strikes and spares. We're going to refactor along the way. Uh, and let's get started and see how this works. So, I'm honestly a little nervous because I said I'm breaking a few of the rules. One of the rules is like actually hovering over your computer uh and writing code. But I've just got an empty directory here. And we're going to start up Visual

Studio Code. Um, starting from scratch. Nothing in I get a lot of warnings because I don't install everything they want me to install. Uh, all right. Are we ready for this, folks? All right. So, you can see I have a terminal window here, and that's where I'm going to do my work with Claude. And then uh is that large enough? By the way, we have a pretty

big screen here. So in the back, can you all see this? Okay. So to fire up Claude, um I've installed Claude Code, which can run from the command line. Uh and so I'm just going to say Claude. And the first thing it asks me is if I trust everything in my folder. Doesn't ask me if I trust Claude. Uh just do I trust my own code? Uh

sure. And here we are. So now we just have a prompt where you can type things. And to speed this up a little bit so you don't see how bad of a typer I am. I have some things that I'm going to just cut and paste. Uh the first thing I'm going to do is I'm going to start with a hashtag. And a hashtag tells Claude you

want to remember something. Uh, and so I'm going to say this project, uh, use as this project uses test-driven development best practices, red, green, refactor. We're pair programming together. I'm going to write a failing test. You should write the simplest thing that could possibly work and confirm the tests are green and we're going to refactor. And I've also noticed that in my case when using cloud code,

I always have to tell it I run on Windows. Uh, it'll actually figure that out eventually. Um, but it starts out assuming you're on Linux or Mac or something. Uh, and it'll try running commands for for those operating systems. Uh, so we're just going to tell it this and we're going to paste that in there. And this is where the live demo gets interesting because we don't

know how long it's going to take. Uh, but it says, okay, just to confirm, we're going to do red green refactor. Now it wants to know what testing framework we're using. What's the first failing test? So it's ready to go, right? Uh so the this is the most important prompt of the ones we're going to do today. And you can create your own version of it. Uh

but I want to try today doing cucumber typescript. And I guess what I already told it it was in this original prompt. I didn't have it remembering that at first. Um, the reason why you want it to have it remembering is like let's say you end your session and then you come back a couple days later. When you pull it up, it looks at the project as

if it's never seen it before. So that's part of the context window. U, so if you initialize, and we're going to show how to initialize, that'll create a file to help remember. And if you put the hashtag in things, that helps it remember. So that way you're not starting over every time you come back. Um, so let's go ahead and tell it to create a cucumber JavaScript

project. I'll just minimize this one a bit. I debate whether or not I like this at the top or the bottom. Um, but yeah, so now it says, okay, the first thing I want to do is npm init. Um, do you want to proceed? Now, this is an important question. If I say yes, um, it'll just do it once. If I say don't ask me again, uh,

that can be very dangerous with AI. So, use your best judgment on what command it's asking you, but pay attention to that. Um, you can tell it that it's okay to commit to branches and to push it to code repos. And it'll commit to branches, it'll push to code repos. Well, what if it pushes to your main branch and it's not a protected branch? Now you've let

AI do a production deployment. Uh so just use your judgment for what you want it to say yes to. For the purpose of this presentation, I also don't want to say yes because I want you to see what it's actually doing. Um okay. So now we're going to do an mpm And it's installing TypeScript and dependencies. You notice I don't have to actually know what npm init

does or what npm install does. Um it's just running it, right? And then you can see over here. Okay, now I have some files showing up. So it's installing the node modules. Uh now it wants to create a directory for putting my step definitions. So this is a cucumber project. So we need step definitions. So now it's just created the directories for me. Uh it looks like

it got the file path wrong. Um I don't know if you see that uh where it says feature step Um but it'll figure it out eventually. Uh we need to add a TS config and it'll show you um you get a preview. Now this wasn't true like a month ago. Uh, but now you get a preview in the in the IDE over here of what files it's

actually creating and you have an opportunity to say no, do something differently and you can reprompt it and it'll correct itself. But let's just chug along. Uh, so now it's configuring TypeScript and Cucumber. Uh, it's saying it's going to create a cucumberjs file. That's what tells Cucumber where to find everything. Uh, still configuring TypeScript and Uh, now it's adding to the npm file the ability to run

tests. So, it's going to use the cucumberjs command to run tests. And on its own, it decided we might want to watch the test running. And so, it also added a a command to watch the tests. Uh, did you notice I'm just pressing enter? I'm not actually like typing anything yet. Uh, have you seen uh The Simpsons episode where Homer gets the drinking bird? Maybe, maybe not.

There's an episode of of The Simpsons where Homer gets a drinking bird that's just sitting there clicking the button on the keyboard. Um, that's all us in next year. We're going to all be doing that. I promise you at some point I'm going to cut and paste some other stuff into this. Uh, so now it's creating a feature file and it's saying as a bowler I want

to calculate my bowling score given I have a new bowling game. The game should be initialized. That's interesting. If you try this and you just say, "Hey, I want to do the bowling game. Uh, set up the project." Um, if you just try that with a blank instance, it will actually give you a project with 12 tests that are already implemented for the rules of bowling as

it understands the rules of bowling. That's crazy, right? And so you're saying, well, if you can just say implement the bowling game, why not just have AI just implement the bowling game and then I'm done. But I want to show you because this is a kata and we're learning the practice. I want to show you the practice of how to implement the bowling game. And you'll see

that it kind of produces a different result when it does it this way. Um, so the I don't know if you saw that, but the test it created I think actually throws an exception when the test is called. Uh, okay. So, I talked about doing things differently. It didn't ask me to do the browser list before. so it's just coming up with its own things of how

it wants to do it differently this time. And now it's running npm tests. So do we want to let it go ahead and run the first test? Let's see what happens. So we should expect a failing test here. Uh, for starters, I think it's not going to find the feature step definitions because it didn't convert the backslash correctly for Windows. Um, you look up So, I don't

know if the test will even run to be honest. Uh, you can see it's kind of running It'll be interesting if it hangs on me. Uh sometimes like um you know I've encountered situations where it just doesn't return and you have to close the window, restart it. Uh you know, we're very much on the the cusp of this new technology. So um all right. So, it says

it says we've got a failing test. I don't know if it's for the reason that it thought. Um, but here it says perfect. Your cucumber TypeScript product is set up and ready to go. Here's what I created. It has a broken feature file. The initial test is green. Um, I didn't know that it was green. Did I Did I miss something? All right. Well, this is exactly

what I'm talking about. So what would I do in this situation? I would come to the directory where it put all the files. I just run npm test myself. Oh, you know what? I know it's green. So maybe we should have looked at the test that we created, right? [laughter] Uh so you can see it did create. Yeah. Okay. There's the source that of what it's testing.

Uh created a feature file that just says the game should be initialized. Oh, okay. It did create our step definitions folder uh here. Um, this is just kind of a weird artifact of it trying to figure it out that it didn't clean up on its own. So, it is using the right folder, but it first attempt was to create one in the wrong spot. Um, I guess

that's what they call QA slop or uh AI slop. So, if you checked that folder in, you're guilty of AI slop because you didn't pay attention to what it was doing and it did something a human wouldn't do. Um, but yeah, look at this. We have given a new bowling game. It's creating an instance of my game. Then the game should be initialized. So, if the game

is not created, throw an error. Uh, I thought it was going to throw this exception if the test was run. Um, but it looks like it's checking to see if something got created. So, this is kind of a silly test. Uh but yeah, let's go ahead and add now we can add our first failing test. So we want to start with the simple example. Um so let's

add a gutter game. So in a gutter game, that's when you're terrible at bowling like I am and almost every ball that you roll lands in the gutter, rolls all the way down, and doesn't hit any of the pens. Uh you will not see me at the international bowling competition. Uh all right. So where do we put this? We can put it in our feature file. And

now we can just paste in the new scenario. And do you see how this is kind of accessible to a wider audience of people to write code? Like here all I'm saying is a new bowling game. If I roll 20 times and don't knock down any of the pins, then the score is zero. To this point, I haven't done anything to tell it anything I know about

npm or JavaScript or TypeScript. All I've said is I'm supposed to write this kind of and I want to start with the failing test. And so now I'm giving it the very first requirement. Uh so now let's go back to let's go back to claude. There's different ways of integrating claude 2. There's a built-in integration. There's a command line one. And actually like two days ago it

popped up and it started showing a graphical version. So do you want the terminal or do you want the graphical version? And so now I have to figure out how do I get my stuff to show up in the graphical version. Uh because it looked really nice. Um but yeah, here we're going to say um I added a failing test. Your move AI. Uh I hope I

click save. I guess it'll tell me. Uh all right. So first I have to give it permission to npm test. You guys have seen this enough. So I'm just going to say always npm test. Uh and the first thing that happens is an error. There's a failure because there's no step definition. Uh and it says now let me implement the step definitions and the simplest code to

pass. So we're cheating a little bit from pure test driven development because I'm also too lazy to write the code for the tests. Um but now it's saying okay and you can see the preview uh you know given a new bowling game when I run it then the score should be so it looks like it's adding some good stuff. You can accept the changes up here or

you can also accept them down there. Um so if you click accept uh now it's actually adding that code to the codebase and it's going to run it. Um, now it's saying let me implement the simplest code possible. And so here, remember how I said with the calculator you might return five. It's saying the simplest thing I need to do for scoring bowling is to return zero,

which from a testing perspective, that's all I've told it. So do I want to go ahead and do that? Let's say yes. So running tests to confirm that we're green. Now it's actually running npm all right so I implemented the simplest code that could possibly work. Um, this is sufficient because everything should res score zero. No refactoring yet needed yet. Last time I did this, it actually

said, "But I want you to know that this would be inadequate because you haven't implemented this other rule of bowling yet." And I thought that was an interesting like, hey, you know, we passed, but you're not done yet. I thought that was actually a helpful suggestion. Uh, all right. So let's add the next one which is if I roll a five then score should be five. Added

a failing test to your move. Uh you can actually also inside the the cloud window you can paste the scenario that you want to add or you can even describe the scenario you wanted to add or you could even describe an entire feature and say create a scenario file for an entire feature if you're that bold. Um, but yeah, so we added the test. It ran the

test. They were red. And it says, great, the tests are red. I expected a score is five, but I got zero. Now, let's do the green step of TDD. Uh, yeah. So, let's just go ahead. So, here's the question. Uh, would we be comfortable pasting the rest of the scenarios in and just saying do all of the scenarios? Who who in this room votes do them one

at a time? And who in this room votes do all the I think the one at a time kind of won, but I venture to guess when you get back to your desktops back in the office and you go through this practice, you're going to start pasting everything, right? [laughter] [gasps] Uh I mean, I would and I I think it's an unknown question, right? If I paste

uh, I at least know that I'm going to get the final result will be that all of the tests are passing and all of my requirements are met and I'm comfortable that the solution I've got is meeting But I know as a developer when I was doing test-driven development and the whole point of the Kotta is to practice how this works. Uh I know when we were

doing that that uh we would want to uh you know do things one at a time so that you're refactoring along the way because you're going to get a different result. Uh and another thing that I did wrong is I normally hold my clicker but because I'm coding I'm getting close on time. So like at work you have to get it to work before the conference your

COO is hammering down on you and even though you know you would get a better quality result if you didn't uh we are going to paste all of the scenarios. So those who voted for that one today because the CEO is bringing breathing down our necks and saying we only have a few minutes left in this presentation. We will implement it and say I added a few

failing tests. Yeah. Two or three questions. Uh yeah. So let's answer the questions while it's running. >> Yeah. Yeah. >> Thank you. As the as the CEO breathing down his neck, which is actually true. Uh first question is and we let it run while it's doing it. What's the difference between Claude and GitHub Copilot I guess in terms of results as I can assume you can do

the same with Copilot as well is the question. >> Gosh, you know I I mean I I like to be the expert um because that's why you stand up here. You're trying to be an expert. Everything changes so fast and so quickly now. It's impossible to stay on top of all of the models. So, what I've personally decided to do um because I've seen clog code produce

really good results is I'm investing more of my time in knowing the functionality of clog code as deeply as I can versus going out and trying to like every new model because there's going to be a new model tomorrow that produces some demo that looks so much more amazing than anything you've ever seen before. Uh so, we just need to place our bets somewhere. Um, so I

actually don't know other than the last time I tried co-pilot, it was providing more of like suggestions in line with the code. Uh, and then the first time I tried cloud code, it was piecing everything apart in terms of here's the plan I'm going to implement. I'll write that plan to a markdown file for you. I'll do the step first step. Do you want to check the

result? I'll do the next step. Uh, co-pilot for me was more of like uh tab completion at the time that I tried it. >> Is it still like that? that I don't >> Right. We have one minute and I think while in the questions maybe just uh what did it do? >> All right. Nuclear option. We're allowing all edits during the session. >> Right. And I think

we have we got one minute. Uh the other question that was what are your thoughts on pair programming in remote teams? Does it work if you can't sit next to someone physically? >> Yeah, I I think it does a lot better than it ever used to. So some of the idees and like Zoom has gotten so much better and it's it's a lot easier to be in

a session where you're working in the same IDE. Um I don't know if it's the same though. >> Um you know one of the aspects of working together with pair programming uh there was a lot of information in just the environment that you're working in like what's the sticky note on the board? Uh, is the database uh is the database architect running around >> right >> waving

his arms? Well, that told me the database wasn't working. >> He's pinging you on WhatsApp instead. Now, uh yeah, we're at time, but it looks like it it's been running some tests. It found some failures and it's doing some refactoring. >> Yeah. So, uh, we we are at time, so unfortunately I'll have to we won't see quite the end, I don't think of it, but, uh, feel

free to catch up with Chris afterwards to, uh, get more insights and, uh, oh, actually, it just finished. Ready for your next building test. >> good job. So, right on schedule. >> Yeah. So, I I hope this, uh, you know, I hope this encourages you to at least uh, try it out in your organization. And I recommend doing the bowling game starting with this and try it

a few times and see if you get the same results because I'm really learning that you get a different result slightly every time you do it. And that's helping me learn how to use not only how to write better code, but now I'm learning also how to more effectively use the AI tool I've chosen because I'm getting a >> Thanks, Chris. Round of applause for our speaker,

Chris. Hey, Brit.