Jeff Terrell: Okay, we'll get started and apologies for the laundry sound in the background.
Jeff Terrell: But hey, working from home. Right.
Jeff Terrell: We're going to talk about testing today. Before we get into it. Let's have some announcements or remember that the final quiz number five is coming up on Wednesday.
Jeff Terrell: And that will actually unlike the previous quizzes include content from Wednesday's lecture itself. So be prepared for that.
Jeff Terrell: We are doing that on Open Class today I I think almost all of you maybe all of you at this point are signed up successfully. So if you haven't been able to sign up successfully for that yet.
Jeff Terrell: Please do so or let me know if you're having issues I have the ear of the guy running this. So if there are any issues, I can just email him and he should be able to figure things out. So
Jeff Terrell: Yeah, that's the plan.
Jeff Terrell: Unless something goes wrong.
Jeff Terrell: Remember that mentor meetings need demos. Now, so we have done the walking skeleton and so henceforth whenever you meet with your mentor you should show him or her the work that you've been doing over the past week.
Jeff Terrell: Ideally, that works should be deployed to production to maintain kind of integration and integration with the deployed environment and everything so
Jeff Terrell: That's the ideal it'd be better to demo from production or potentially a staging environment rather than demoing from your
Jeff Terrell: local environment, just so that you avoid running into issues later when you try to deploy a whole bunch of stuff at once.
Jeff Terrell: I think, apart from the Tech Talk. Most of your assignments. From this point forward are pretty straightforward and easy today. This is gonna today and Wednesday we were talking about testing and this will cover a lot of what you need to know for the test coverage assignment.
Jeff Terrell: But yeah, most of the assignments are pretty lightweight, so I do expect that the focus of your efforts from here on out. Now that the walking skeleton is done.
Jeff Terrell: Will be less than assignments and more on just implementing the features that your client needs you to implement or want you to implement
Jeff Terrell: Alright grades are up to date as of noon today.
Jeff Terrell: In fact, I don't think I have any more information about grade. Since then, either. So maybe they're up to date as of now.
Jeff Terrell: The tech tight schedule and topics have been finalized and posted to the class website on the calendar page. So check that out if you're not sure
Jeff Terrell: When you're presenting, or if you're just curious what's coming up in the next few lectures, we will have six teams presenting next week six. The following week six. The following week and then three, the final week which will be the last day of class.
Jeff Terrell: So we got that all lined up. All right, I got a question. I thought was a good one. Like what counts is active learning and your tech talk
Jeff Terrell: The basic ideas that I want you to be involving the, the students in the class.
Jeff Terrell: In your presentation, somehow. So a good way to do this would be some kind of an exercise or potentially a tutorial that students can follow along with as you're presenting. So, you know, this could be something like a code sandbox.
Jeff Terrell: Or what's the other one. There's like JS been maybe there's some of these things out there especially for web apps that make it easy to share
Jeff Terrell: Code and the results of code for a web app. I think there are similar things for mobile app, maybe something like snack, if I remember right might work for a mobile app.
Jeff Terrell: Might be React Native only. I don't know. Anyway, so be thinking about, you know, how can you get your get the audience involved and get them learning not just by listening or watching but learning by doing as well that's active learning
Jeff Terrell: Yeah. And I mean, feel free to get creative to. It doesn't have to just be a tutorial but just any way that you can get the audience involved. I think is, is good there.
Jeff Terrell: Any questions about assignments.
Jeff Terrell: Don't see anything in the chat.
Okay.
Jeff Terrell: All right.
Jeff Terrell: So I wanted to introduce testing by talking about kind of an example of
Jeff Terrell: What, what could happen after this semester. And what often does happen with 523 projects.
Jeff Terrell: So the client that you're working for needs some bug fixed or some feature added but you graduated and moved on to work for some awesome company.
Jeff Terrell: You're adding here, you don't have time to mess around with these old 523 projects that was what got you hired and now you got hired you don't you don't have time to mess around a fat.
Jeff Terrell: And so the client has a nice who has a friend who knows how to code and this friend sees this code base that you and your team wrote and needs to figure out how, how can they do the change that they need to do, and how can they feel confident that when they actually deploy.
Jeff Terrell: That they're not going to be breaking things
Jeff Terrell: Alright, so the answer is testing. Let's, uh,
Jeff Terrell: Let's, let's, let's talk about another example. All right. Let's make it a little bit more personal.
Jeff Terrell: You graduate and you move on to, you know, some beautiful location work for some awesome company, your first assignment is to add some feature to the flagship half of this company, how you learn the code base and feel confident that you are breaking something just to make it more personal.
Jeff Terrell: That's kind of hard right you're you're jumping into some big code base that you've never seen before.
Jeff Terrell: There's maybe a ton of work has gone into this code base already. And so there's thousands and thousands of lines of code, maybe even millions in some cases.
Jeff Terrell: There's a bajillion different files and modules and classes that you can look at
Jeff Terrell: And you have to figure out somewhere in this sea of code. Where do you actually need to go and what changes do you need to make
Jeff Terrell: And that can be pretty challenging thing to do and then furthermore like the number of features that are in some of these, you know, mature code bases that a bunch of engineers have been working on full time for years.
Jeff Terrell: There's a ton of different things that this program needs to do and support. And so you're not as somebody new to that code pace going to have
Jeff Terrell: Any confidence that you understand all this supposed to happen, right. You think you're trying to extend some some code to add some feature.
Jeff Terrell: And you see some code that looks kind of weird. And you're like, Well, I don't know whether that was intentional or not. Maybe that's exactly the way it's supposed to be. It's really hard to know.
Jeff Terrell: And you know you need to mess with that code to add your feature. So what do you do
Jeff Terrell: It tends to produce a lot of hesitation and uncertainty and you tend to go really slow. And it's uncomfortable to write. It's like, Gosh, I don't know what I'm doing. I feel very unprepared to actually make a change and really
Jeff Terrell: You know XPS one of the expertise values is courage and you just lack that courage, because you don't know
Jeff Terrell: Right. So the answer to this is testing. The point is that an app with automated tests covering all of the important features is far easier to contribute to
Jeff Terrell: Right, so, so let's tell the story again with automated tests in the picture. All right, so you graduated you moved on to some beautiful location to work for some awesome company and your first assignment is to add some feature to the flagship app.
Jeff Terrell: Well, first you get a dev environment setup to see the effects of your changes. Maybe you followed a really well written, read me
Jeff Terrell: That you didn't even need help getting into development environment setup the readme really walked you through it and you were able to go get all the things you needed
Jeff Terrell: Find you know the Docker images or whatever it is that you needed to get your development environment setup and you just ran the commands and it works.
Jeff Terrell: Then you have development virus set up to where you can see when you make some changes to the code, you can actually see the results of those changes right there in your own environment.
Jeff Terrell: So then that's great. You add some code to your future.
Jeff Terrell: To implement your future. And then if you're not sure whether you broke. Anything else we just run the comprehensive test suite to be sure you haven't broken anything else.
Jeff Terrell: Easy, easy, easy and you can have confidence. I mean, maybe. Maybe it takes a while. Maybe it's a little bit cumbersome, because it takes 15 minutes to run through all the different features that that there is but at least this way, you know, okay, I didn't break anything
Jeff Terrell: And furthermore, with a team like this.
Jeff Terrell: There's typically an expectation that if you broke something. But that's something wasn't covered by tests. It's not your fault.
Jeff Terrell: It's not your fault if you broke it and there was no test case that alerted to that fact. It's not your fault is actually the fault of the person who wrote that feature in the first place and didn't add tests for it.
Jeff Terrell: So hopefully you can see and get a feel for
Jeff Terrell: How this is
Jeff Terrell: A really nice place to be. When you're in a team when you're new to a project when other people are new to a project.
Jeff Terrell: And even just the steady state. Let's say you're familiar with code, the code base that you're working on. It's still nice to have this right because you're not
Jeff Terrell: Familiar necessarily with every nook and cranny of the code base. There might be some corners that you haven't explored and maybe it's been a few months or years since you saw particular module and thought about it.
Jeff Terrell: So even in a steady state. It's really useful to have this and it really helps confidence of all the developers to be able to develop
Jeff Terrell: The confidence to get things done.
Jeff Terrell: Right. So then in fact your code can't be deployed unless all the tests pass. So there's even like safety nets to prevent you from accidentally doing something destructive or hurtful.
Jeff Terrell: And so, that feels all the more safe and you have all the more confidence that things are going to go fine you can just make your change. And if there's a problem. You'll, you'll find out.
Jeff Terrell: Right, and then a lot of times these kinds of teams have a culture where it's like if you're adding code, but you're not adding tests for that code.
Jeff Terrell: You're, you're gonna you're gonna get called out for that and say you got to add test for this to maintain the health of our test suite and the overall that because next person along might break your feature without knowing it, because you didn't add tests.
Jeff Terrell: Right, so that's a much happier story. And the idea here is a tests and automated tests that all developers can run
Jeff Terrell: Really helps that
Jeff Terrell: Okay.
Jeff Terrell: Now, kind of a historical notes to give you a feel for what things were like before automated tests for mainstream
Jeff Terrell: And I should say there's there's
Jeff Terrell: I don't know my history here probably I suspect there were some form of automated tests, dating back to the 60s would be my guess that people would test their code and the system there that everything worked right
Jeff Terrell: Probably having that tests written as a program
Jeff Terrell: Probably days back at least that far. I don't really know.
Jeff Terrell: But I'm really talking about more in relatively recent times when testing and automated tests weren't necessarily mainstream
Jeff Terrell: Well, as you might can imagine it was a lot more common for things to break if you don't have automated tests things tend to bring more often you don't have that constant visibility to ensure that this feature is still working the way that it should.
Jeff Terrell: Now some tests, some shops have a manual testing scripts. This is like
Jeff Terrell: Okay, before you release and deploy this new some new code some new version of the code you need to look through this, you know, Google Doc or this wiki, wiki, Doc.
Jeff Terrell: And there's 50 different steps you need to take you need to click here and do this and you should see this and you should click there and you should see that
Jeff Terrell: And
Jeff Terrell: Sorry. And this is really not fun, right. This is not a fun thing to do. And then if I'm a developer and I need to walk through this manual testing script. I'm like, Oh, gosh.
Jeff Terrell: This isn't. I just have to go and click through every single little thing all over again to make sure nothing broke. It's going to take me an hour.
Jeff Terrell: I have to do all these different steps I do the same thing every time. And basically, you're going to say like
Jeff Terrell: I don't want to do this anymore. Often that I have to. Can we can we wait to deploy, you know, can we just do this at the end of the month, and only have to suffer through that once
Jeff Terrell: And it's going to be more error prone, right, you're going to be tempted either either you're tempted to take shortcuts, you'll be like, yeah, I know this section of the script says I'm supposed to do all these 15 things but
Jeff Terrell: This stuff doesn't touch that code.
Jeff Terrell: That feature is fine.
Jeff Terrell: I shouldn't have changed. So I'm just going to skip that. Because I'm pretty sure there's no bugs there.
Jeff Terrell: And sooner or later get bit by it and there wasn't bug there. Right.
Jeff Terrell: So it's error prone and even apart from taking shortcuts. It's just your human right. Sometimes you get fatigued and make mistakes. So this is definitely not a good way to go.
Jeff Terrell: In fact, I had a freelance gig once where I had to do this, this manual testing and it had all these effects. I don't know that I
Jeff Terrell: Like I'm pretty detail oriented and fastidious, and I don't think I ever failed to go through the entire script, but it wasn't a fun day when I had to do this.
Jeff Terrell: And I did want to make releases and frequent because it was just overhead that I had to pay like I could be adding more value by actually working on code and features.
Jeff Terrell: So, so I've kind of lived through this, to some extent, I've been on another gig, where there was actually a QA team, the QA stands for quality assurance.
Jeff Terrell: And this is kind of nice because from a developer's perspective. I'm not the one that has to go through the manual testing script. And so, okay, that's a lot nicer for me. And some people actually really enjoy doing QA work. I don't relate to that but but some people do.
Jeff Terrell: So it can be fun and rewarding thing for them. But even if it's a fun thing, even if it's even if they, they are not error prone and they do a very good, thorough job every time it still tends to make releases less frequent
Jeff Terrell: And remember we talked about system agility before when we talked about like DevOps and things like that. Having being able to have frequently releases and agile systems is a really big win.
Jeff Terrell: Alright so automated tests help you avoid this kind of pain, which is which is good.
Jeff Terrell: Questions so far.
Jeff Terrell: Okay.
Jeff Terrell: As this as a quick aside, there are some alternatives to testing, for example, static type, type systems are kind of seen as the main alternative to tests they can catch a lot of errors before deployment.
Jeff Terrell: Before runtime and, you know, to some extent, something like Java can help with this, something like TypeScript can help with this, but there are there's stuff out there that is really advanced in terms of what kinds of
Jeff Terrell: type errors that it can detect and find even just a compile time before program is run and Haskell is a really good example of this. They can catch an amazing amount of different bugs just purely based on the static type system.
Jeff Terrell: I'll be teaching. I don't know how deep, I'll go into this topic, but I will be teaching stuff to touch touches more on this next semester. If you're interested, that's type 24 sweat. I'll be teaching programming languages.
Jeff Terrell: But even there. If you have a fairly complex Haskell projects, then it's likely you're still going to have tests because guess what types don't catch every bug.
Jeff Terrell: Nor do tests. And so there's no guarantee when it comes to this kind of software. And that's why the word that we're using a lot is confidence. It's not about proof. It's not about guarantees, it's about having confidence that what you're writing is going to work.
Jeff Terrell: Okay, so I said all that, by way of introduction
Jeff Terrell: And next, I guess just an outline for the the lecture today I'm going to talk about seven reasons why testing is a good idea.
Jeff Terrell: And then also, I'll talk about why testing isn't a good idea. I'm just kind of being able to weigh that decision. I'm going to talk about different types of tests like unit tests integration tests and end to end tests.
Jeff Terrell: Will talk about test coverage, which actually is the most directly relevant for your upcoming assignment. I think it's do the week of November 1 on your test coverage report.
Jeff Terrell: And if we have time, we'll get to test driven development as well, which is one of the XP practices that you might remember
Jeff Terrell: All right, why test seven reasons. One, most importantly tests give confidence. I've already said that a couple of times.
Jeff Terrell: I gave some examples of stories of how if you don't have tests. It's hard to know if you broke something.
Jeff Terrell: And even apart from even apart from breaking other features. It's nice to write tests and have tests for the feature that you're working on right now so that before you say this is done. You've you're confident that it really does work the way that it's supposed to.
Jeff Terrell: Remember XP has a value of courage.
Jeff Terrell: Tests enable Courage, Courage and confidence are very closely related things. We could probably almost use those words interchangeably.
Jeff Terrell: And this is really, really a big deal.
Jeff Terrell: This is actually the most important reason to write tests is to give confidence that what you're writing is correct and hasn't broken anything
Jeff Terrell: That just greases the wheels of all the development. It helps everybody be productive and stay moving and not hesitate about, well, I don't know if this is really going to work or not. I'm worried about a bug or
Jeff Terrell: Worried about breaking something if you have the tests, you can just deploy, you can have confidence. You can keep moving and things tend to go a lot smoother. So this is the most important reason to write tests.
Jeff Terrell: Another reason and these are not necessarily all in order. I did do the most important one first. But the other ones are just other reasons, without a particular order. Second reason you get the perspective of the collar.
Jeff Terrell: And what this does is it aids the XP value of simplicity
Jeff Terrell: Because you keep things minimal right you don't write code that you don't need because you're only writing code at the collar is actually going to need, right, you're not going to write a function that isn't actually used because
Jeff Terrell: You're only writing the tests or you're only writing code, the past the tests. And once you have that perspective of the collar. You realize kind of what made what the simplest path to getting to a solution is
Jeff Terrell: And you just work on that. Remember we talked about Gagne you ain't gonna need it in the context of simplicity. So testing actually can make your code simpler.
Jeff Terrell: Number three tests documents developer intentions.
Jeff Terrell: And so you're looking at some function and you're trying to understand the code, but it's like 40 lines long. And it's a little bit hard to understand all the different cases that this function is intended to handle
Jeff Terrell: It can be a lot easier just to read the test suite for that function and say okay if I call it like this.
Jeff Terrell: I should get this output for color like that I should get that output. Okay, that's making sense. A lot of times when you see the examples, it's a lot easier to understand what the function is doing, rather than looking at the implementation of the function
Jeff Terrell: You can also capture like a developer's writing tests for a function that he or she wrote can capture what they intended
Jeff Terrell: How that how that function was supposed to be used and the different cases that were explicitly support it.
Jeff Terrell: Yeah I did write a function that takes an array, but I'm also making it work with maps. So it actually can accept either one.
Jeff Terrell: How do I know that well because I wrote the test for it or how does one. How does one of my developers know that well maybe by the doc string. That'd be good to that maybe also by looking at the test suite to see that it's actually called both within array, and with a map.
Jeff Terrell: Okay tests reveal regressions is number four. We talked a little bit about this already. If. How do you know you broken existing feature or how do you know whether you prefer an existing feature while your tests can tell you
Jeff Terrell: This is a lot better. By the way, than waiting until some user notices that something is broken and let you know because by then probably 100 people have seen that there's an issue.
Jeff Terrell: So a test suite is a gift to future developers on the project, including yourself right when you start to forget what you wrote six months ago or six years ago, being able to have your tests as a gift to your future self.
Jeff Terrell: fifth reason to test tests, close the time gap.
Jeff Terrell: Expert programmers use tight feedback loops to iterate quickly. Those of you in my 590 class last semester I probably have heard me say this enough that you're sick of it but feedback loops are really
Jeff Terrell: I think they're one of the key things that distinguish a really good programmer from one who isn't as experienced and isn't as productive. But if you can have a tight feedback loop and you're getting feedback on what you're writing right now.
Jeff Terrell: That can be a big deal to maintain traction on the project and continue making progress and not to get stuck.
Jeff Terrell: So the idea here is that if you have a really tight feedback loop, which means you're getting feedback really fast, like say you you save a file.
Jeff Terrell: And then within 100 milliseconds. Your, your knowing whether your tests past or not based on the current, current contents of the file. It just got saved.
Jeff Terrell: You might as well trigger that often, right, you might as well make one small change kind of the minimal change that you possibly make hit save, see the result of whether your tests past or not. And if it doesn't, if the test doesn't pass, then
Jeff Terrell: Guess what the bug that you introduced was code that you wrote in the past 30 seconds, there's a good chance you know exactly what the bug is given that the search space is so small and so top of mind. It's so fresh and there's so little code there that you actually change.
Jeff Terrell: You're probably just like, Okay, I know exactly what that is. I can fix that and we'll keep going. Even if you don't you just hit on do a few times, get back to where you were. And then think about it more carefully.
Jeff Terrell: And then once it works. Once you get your tests passing. You can forget all about this stuff that came before and just focus on the next thing. So, it enables this like laser tight focus on what you're working on.
Jeff Terrell: One small step at a time. But really rapid steps one after the other. And it feels good. It feels like I am making progress on this thing. And I'm moving fast I'm getting stuff done. I'm not getting stuck you get into this creative flow state that just feels good.
Jeff Terrell: The key idea here is that rapid tests enable rapid iteration.
Jeff Terrell: And even slow tests, close the time gap in the sense that they help find bugs before users do
Jeff Terrell: Alright, a couple more reasons here tests enable refactoring. Remember, there's an XP practice of refactoring.
Jeff Terrell: The catchphrases red green refactor meaning write some tests that aren't going to pass first to indicate what needs to happen then make your tests pass by writing code that makes those tests pass and then refactor your code to keep things as simple as they can be.
Jeff Terrell: So once you have those passing tests at the green state. You can clean things up and make them make everything nice and tidy.
Jeff Terrell: refactor pull out duplicate code into a function or whatever you need to do.
Jeff Terrell: And this is decoupling getting it working from getting it simple. And that's a really nice thing because it can remove a hang up on your
Jeff Terrell: I guess they said that a couple different times over, anyway.
Jeff Terrell: It removes it the hang up of, like, oh, I don't want to write this until it's perfect. I need to think about this carefully. It's like, no. Just, just write it. You can clean it up later.
Jeff Terrell: And that those rapid tests, give a tight feedback loop, not just when you're implementing the code, but also when you're refactoring it so you can refactor one tiny little thing at a time.
Jeff Terrell: I get some advice from my PhD advisor here at UNC Don Smith. I wonder if some of you might have had him for a class.
Jeff Terrell: He told me some advice when I was writing my dissertation.
Jeff Terrell: He said brain dump everything in your head about your topic. First, just get it all out into some file or, on paper, or something. Just get it out of your head. Once it's out. You would be amazed at how much you can clean up after the fact.
Jeff Terrell: And I took his advice. And he was right. It was amazing to me how I could start with a complete pile of just mess.
Jeff Terrell: It was all the stuff that I could think of to say and then as I started to read that I could start to see the themes I could start to see an organization and some structure that I could use to organize this stuff.
Jeff Terrell: And it worked. I ended up. It was a really good way to keep me from getting hung up on writer's block and not knowing where to start and stuff like that.
Jeff Terrell: Hemingway has a version of this, I hear, I didn't actually chased down whether this quote is the jet, but it's he says right drunk edit sober.
Jeff Terrell: When you drive just make a sloppy mess but get it all out there and then you can edit when you're sober.
Jeff Terrell: seventh and final reason to test I talked about this a little bit already testing can be fun. Alright, if you're taking small steps and making steady progress that feels good.
Jeff Terrell: And it helps you get into this mental state called creative flow and that just it's, it's an addictive thing, as some of you have experienced this already, and
Jeff Terrell: It's what keeps you coming back to program you get into this state, some times where it's like, man I am I am rocking this feels great. I'm making progress. I love this. I'm like exerting my will, into the system. I feel powerful. This is great.
Jeff Terrell: This happens in all sorts of creative media, by the way.
Jeff Terrell: Artists, I have a an uncle who's actually been some CAD work like AutoCAD and stuff for for building blueprints and he gets into the state. Sometimes we talked about that. It's pretty cool. So
Jeff Terrell: Regardless of your medium, you can get into the state and it feels good.
Jeff Terrell: Worst experience in programming. And my experience is feeling stuck on something pair programming helps with this, but also having the tests as a feedback back loop really helps with this is just a lot harder to get stuck.
Jeff Terrell: When you have that feedback coming back. Alright, so those are the seven reasons to test any question about any of these
Jeff Terrell: Tests give confidence. You get the perspective of the color.
Jeff Terrell: Tests document developer intentions and reveal regressions.
Jeff Terrell: Close the time gap. They enable refactoring, and they can just be fine. They can make programming fun
Jeff Terrell: No questions.
Jeff Terrell: Okay.
Jeff Terrell: All right. Let's balance that a little bit. Why shouldn't you test or what are some reasons not to
Jeff Terrell: Tests add complexity to the projects. All right, now you're not just writing code, you're also writing tests and so
Jeff Terrell: You might double the amount of code that's in your code base, just by committing to writing good tests might even triple it, you know, it could be even even bigger than that so
Jeff Terrell: You know you're adding a significant amount of work and this is probably the main reason why sometimes it makes sense not to test is that sometimes the complexity just isn't worth it.
Jeff Terrell: That said,
Jeff Terrell: Complexity is kind of an aside, car, so to speak, meaning that all your tests. A lot of times are in a separate directory and our kind of out of sight of the implementation itself. So it's not like you're
Jeff Terrell: You know, adding a bunch of noise to your actual source code and that just is getting in the way of, of what you're doing when you're reading code and understanding what it does.
Jeff Terrell: Furthermore, when you get the perspective of the collar and when you have tests that enable you to do refactoring that can really help keep things simpler.
Jeff Terrell: And pay for some of the complexity that comes along with testing. In fact, in some cases, you could actually add tests and reduce complexity because of the simplicity that you can unlock by having tests.
Jeff Terrell: I just I just saw your comment. Yeah. The only thing less fun than writing tests is dealing with the fallout from that writing them. That's right. Test serve your future self.
Jeff Terrell: Okay, second reason not to test would be to just realizing the tests don't catch every bug. So if you're thinking that testing is going to be a silver bullet. It's going to be a panacea. That's not an accurate understanding of testing.
Jeff Terrell: But testing does catch many bugs. And so I think a lot of times it is worth it. Even if you know it's not going to be 100% effective at catching everything
Jeff Terrell: Third and final reason not to tests is that test sad inertia to the interface. So there's, I wish I could get into this more. There's a really good distinction to be made between the interface of the code and the implementation of the code.
Jeff Terrell: The implementation is the low level features of how it actually works. But the interface is like what are the ways you can use it.
Jeff Terrell: And what are the the commitments that this code needs to honor, regardless of what form the implementation takes this is an important concept in a variety of arenas. I hope you've seen enough of this and other classes such as for was it for one that
Jeff Terrell: That this makes sense but refactoring, for example.
Jeff Terrell: technically means that you're changing the implementation, but not the interface. So technically, if you are changing the interface.
Jeff Terrell: That means that you're doing something beyond refactoring. You're, you're sort of rewriting some code and you're changing some requirements and
Jeff Terrell: That's a heavier change, it's a little bit harder to do the point here that I'm making about testing is that changing the interface is harder to do when you have tests backing your code.
Jeff Terrell: You not only at that point have to change your code. You also are breaking tests when you make those changes because you're not just testing the
Jeff Terrell: Sorry, because your, your tests work against an interface, the same way as other code does. And when you change the interface you've kind of moved the target out from under the test and you've broken them.
Jeff Terrell: And so if you're going to make a change like that you're going to end up having to change the code as well as various tests that are broken along the way.
Jeff Terrell: Which means you've added some weight to your code base and made it a little bit harder in some ways to be agile, at least in some respects.
Jeff Terrell: So ideally, avoid changing the interface. But that's not always possible. Sometimes your interfaces terrible and you realize that some point down the road. This interface is just not going to cut it. I need to extend it too far. I need to start over.
Jeff Terrell: So if it's x just redo it. Remember the XP value of simplicity simple
Jeff Terrell: Anyway, the point here is a test to add inertia to the interface.
Jeff Terrell: So that begs the question, we talked about why not to test and why to test and how do we resolve this tension.
Jeff Terrell: My standard recommendation here is that if you're working on throwaway code or short lived experiments or explorations don't test. It's not worth. It's not worth the complexity.
Jeff Terrell: But anything else that project that lasts more than a month or two, I would say test, and that includes all of your contract 23 projects.
Jeff Terrell: All of your projects are our long lived and hopefully will be long enough as your client uses this app that you're creating and maintains it in the future, maybe more developers, come on to the project and work on it.
Jeff Terrell: So what you're working on this semester for this class is along with the project and I do recommend testing and
Jeff Terrell: Yeah, in fact,
Jeff Terrell: Oh, talk about it later. Yeah, okay.
Jeff Terrell: Questions so far on why the test or why not to test
Okay.
Jeff Terrell: All right, we're going to switch gears here a little bit and talk about different types of tests.
Jeff Terrell: Let's just dive in. So there's there's three main types. And if you've done much kind of in the real world and internships and stuff like that. And you've been in an environment when where a development team is
Jeff Terrell: Writing tests and are committed to that you've probably heard some of these terms.
Jeff Terrell: But let me break down kind of what these are. So we've got a unit tests. We've got an integration tests. We've got an end to end test often abbreviated ed d e to e
Jeff Terrell: So unit test is just testing a single component in isolation.
Jeff Terrell: And integration tests this when you have more than one component your testing has several components are working together correctly.
Jeff Terrell: Finally, an end to end test is one where you actually have a scripted robot that operates as a user does
Jeff Terrell: So if you're building a web app. This robot is actually using a web browser. Clicking on things reporting what it can see in the web browser. If you're using a mobile end to end test and you've got some sort of a robot that can open an app on a simulated phone
Jeff Terrell: It can click around within that app, it can report about what it sees and you can script it to both do things and to, you know, report, whether this element was present in the page or in the screen.
Jeff Terrell: That's an end to end test. Alright, so talk about unit tests.
Jeff Terrell: The goal, as I said, is to test one component in isolation from any other component component, it's typically going to be like a function or a class.
Jeff Terrell: It could be potentially a method of a class, especially like a static method.
Jeff Terrell: You can use test doubles, which we'll talk about later to achieve isolation that doesn't otherwise exist. And so if you have like one function that's calling another function.
Jeff Terrell: You can insert a test devil sort of in between the two and say, rather than calling that other function. I'm just going to give you something to short circuit that
Jeff Terrell: And this is a useful technique. In some cases, I don't think we're going to get to that today, but maybe next lecture will get to talking about test doubles a little bit
Jeff Terrell: Note that if you have a pure function, which doesn't have any effects and just accept certain things as arguments and returns whatever it returns, and that's a completely deterministic thing.
Jeff Terrell: Pure functions are dead simple to test, you know, did these arguments result in this return value.
Jeff Terrell: And that's, it's a really simple test to express. So for example, you know, does add given eight and seven return 15 so your test fast just dead simple concept.
Jeff Terrell: Or to talk about an object oriented programming example, if you had some class CSV data and you gave it some CSP string and the constructor.
Jeff Terrell: You could create the CSV data object, you could call it out columns on it and you would assert that what you get back is called one call to an array.
Jeff Terrell: So that's a unit test that's intended to test a single component in isolation and this is also testing a single unit in isolation.
Jeff Terrell: I should have said this in my slides. But when you're writing tests. A lot of times I you might have seen an abbreviation su t if you've been in industry and this typically means the system under test for
Jeff Terrell: That's usually what it means system under test. So if you're running a unit test.
Jeff Terrell: The, the short abbreviation for like the thing that I'm actually testing might be su team.
Jeff Terrell: integration tests are unit tests, except with more than one unit. So the goal is to test several different components or units working together.
Jeff Terrell: To accomplish some some task. Alright. Several could be as few as to if it's fewer than two. It'd be a unit test.
Jeff Terrell: It could be 500 or more. There could be a bunch of different units that you're testing that they all work together. So there's a really wide range of what an integration test could be technically speaking, end to end tests our integration tests.
Jeff Terrell: There are certain kind of integration test is kind of at the extreme end of how many different things are being integrated, but the fact that they are integrating more than one unit when they run the test means that they are a type of integration test.
Jeff Terrell: So an example here. Imagine that we had our CSV data class. And then we had another class CSV data file that
Jeff Terrell: Used the CSV data class that we had already created. So in that case, a simple test assertion in integration test might be that
Jeff Terrell: You create a new CSV data file instance, giving it the data CSV file name as the construct your argument then you call columns and okay then you again you could call on a call to but see at this point for testing that CSV data file, together with CSV data.
Jeff Terrell: Did what it needs to do together. You know that the one could call the other and we get the right result. So if there's a bug in CSV data. This test is going to fail.
Jeff Terrell: Or if there's a bug in CSV data file this tests could also fail so it makes it a little bit harder to know if there is a failure, where the failure is because we're integrating multiple things together and it could be in any of those things that we're bringing in
Jeff Terrell: But, but, yeah, that's awesome integration test. Another example would be
Jeff Terrell: Trying to log into the back end, you know, you're writing some back end. And you're you write a test that tries to login with the to the back end with invalid credentials and you assert that that should return a 403 forbidden response. So again, another example of an integration test.
Jeff Terrell: Okay, I don't see any questions so far end to end tests abbreviated etc. The goal here is to test the entire system as a user
Jeff Terrell: And so typically, you're going to have to have some sort of fancy tool to navigate a user interface. And if you're creating a graphical user interface, you're going to need something that can navigate a UI.
Jeff Terrell: So Cyprus is actually a really good tool that uses JavaScript to drive a browser through your app is a really great tool. If you're writing a web app.
Jeff Terrell: Even if you don't use JavaScript for the rest of your code, you can still write your test suite in JavaScript and new Cypress
Jeff Terrell: Cypress is nice because it does fire up a browser and run that through your app.
Jeff Terrell: And your scripting right your scripting that robot to do what it needs to do, and to make various assertions about what's in the page.
Jeff Terrell: But Cyprus is nice because it's if there's a failure or maybe, maybe even if there's not. It'll. It'll take screenshots of the browser at different points like when the test failed or whatever. So you can maybe see, oh, this didn't work because there was an unexpected error on the page.
Jeff Terrell: It can do other things too. I think it can actually record videos of the robot, you know, driving the browser.
Jeff Terrell: And robots more of a virtual concepts, not like you can see a robot doing things that's just kind of the idea there.
Jeff Terrell: Yeah, that's an end to end test and
Jeff Terrell: This is easier to to do in some cases than others Cyprus's are really good for web apps. But other
Jeff Terrell: Technologies that you're using are going to be harder to write to write an end to end test.
Jeff Terrell: And I want to talk about the trade offs. Like why would you pick one type of test over another.
Jeff Terrell: First of all, implementation difficulty is one of the the spectrum that one of the spectra that we're looking at here, one of the dimensions. Maybe I should say.
Jeff Terrell: And in that dimension. Unit tests are almost always going to be the easiest thing to write if you're dealing with just a single unit of code that can be
Jeff Terrell: The easiest kind of test to write almost always this integration tests are harder because you've got multiple units and end to end tests.
Jeff Terrell: You've got to figure out how to drive that robot and interpret the results and all that. And that can involve fair bit of tooling complexity. So unit tests are easiest execution speed we talked about how rapid feedback loops enable rapid iteration.
Jeff Terrell: And unit tests. There are the winner is again. Unit tests are the fastest
Jeff Terrell: So if you want a really tight feedback loop unit tests might be the way to go.
Jeff Terrell: But there's another dimension here, which is the amount of confidence that a test delivers to you as you're writing the code.
Jeff Terrell: And then that dimension end to end tests are very valuable right you're you went so far as to pull up a web browser and click through it. So if there's anything that doesn't work. That's going to find it.
Jeff Terrell: So I'm
Jeff Terrell: So into n tests are are worthwhile, even though they're harder to implement and they tend to be a lot slower.
Jeff Terrell: So the main suggestion here is to make an informed choice. That makes sense for your project.
Jeff Terrell: All right, think about what does your project need and what tests, make the most sense for your project.
Jeff Terrell: I will say it's rare to find a project that only has one type of test.
Jeff Terrell: There are occasionally people who are very insistent about
Jeff Terrell: Their tight feedback loops and they would say you should only do unit tests and you should use test doubles everywhere so that you can isolate all of your individual units.
Jeff Terrell: And that is pretty cool because you could run a test suite for a fairly complex app like within a second, you can run all of the tests and it's, it can be pretty nice.
Jeff Terrell: But it's also it can be difficult to set up and there are bugs that can slip through the cracks in a case like that because you're never actually testing that one component one unit is integrated with another one successfully that all the glue is correct.
Jeff Terrell: Let's see. Yeah. And I'll say that I'm going a little bit out of order here. I'll say most components are not isolated.
Jeff Terrell: I think I said that before. And so test levels might not be worth it. Just because they can be a bit of a hassle to get going.
Jeff Terrell: Once you get fluent in them. They can be easier. And you can feel like, Okay, I know how to do this. This is not a big deal. I'll just write an isolated test here and use test devils to do it, but some, but it's a bit of
Jeff Terrell: A bit of a learning curve to do that. And again, you, you lose the benefit of an integration tests which is making sure that two things are glued together correctly.
Jeff Terrell: Two or more things.
Jeff Terrell: But yeah, in some cases, you're going to say testable just aren't worth it. Maybe I don't know them very well, or maybe
Jeff Terrell: It's just not worth it.
Jeff Terrell: Right so various people have strong opinions about testing. Maybe if you were an industry for a while and an internship or something like that. You may have seen this, people have opinions about this. And depending on
Jeff Terrell: Who's in charge and what the culture of a company in a team is there might be certain kinds of testing that are recommended for a given project and other kinds of testing that frowned upon.
Jeff Terrell: And that's just whatever you know culture you get into and whatever whatever team, you get into and what their values are
Jeff Terrell: My main suggestion here. Like I said make an informed choice. That makes sense for your project, but I have one other suggestion that I kind of wish I had spent a little bit more words to elaborate on because there's a lot of depth to it.
Jeff Terrell: And that's this one here, a tackle variation of where it lives.
Jeff Terrell: Um, the, the idea here is that if you had
Jeff Terrell: If you were only going to do end to end tests.
Jeff Terrell: But there was like a different flow for
Jeff Terrell: Let's see. Maybe you signed in with an email and password. And maybe you can also sign in with Google.
Jeff Terrell: A Google account.
Jeff Terrell: Okay, fine. Those are that's that's one choice to the user estimate. Then they have some preference that says whether they get notifications for not
Jeff Terrell: Okay, so there's another choice. And you can imagine just a series of different choices, let's say, each of them is just a binary sort of on off thing.
Jeff Terrell: That these things compound. And so if you wanted to actually test the integration of all of these different pieces and all the all the variation that exists across your entire app.
Jeff Terrell: You know, let's say you had 10 things, each of which was a binary switch and you're only ever doing end to end testing you would need 1024 right to do the 10th.
Jeff Terrell: And then end test cases to cover each one of those possibilities and nobody is ever going to do that.
Jeff Terrell: That's, that's, I mean, who knows, maybe in some really important robust like cannot fail mission critical system. Somebody would go to that length, but it's just not a good way to go. You can get to that point.
Jeff Terrell: And have a lot of confidence. Without that, that by just tackling a variation where it lives. So, you have, you know, your authentication either Google or email based
Jeff Terrell: So write a test and they've been integration tests that focuses on the authentication piece and covers that variation there you cover both cases there you get both sides, covered with tests.
Jeff Terrell: And you're good to go do another one for an whether notifications are on. And what does that mean, you know,
Jeff Terrell: Do I actually get a notification when I have this setting enabled. Do I not see the notification when I don't have that setting enabled.
Jeff Terrell: For cover both of my cases right there where that code lives, maybe with the unit test or an integration test there. And then it's a lot easier to write to test. And so you end up having to write 20 tests, instead of 1024 you can kind of see where this is going. Maybe
Jeff Terrell: If you tackle variation where it lives. And so it's an anti pattern. I would say to get too happy about an ETA tests because they're just so heavy weight and if you had
Jeff Terrell: An Ed test suite that actually had 1000 cases in it. It probably take hours and hours to run and that would be such a slow feedback loop that it would be, I think, really frustrating.
Jeff Terrell: Okay, so I was a lot there.
Jeff Terrell: I'm talking about a lot of this fairly abstractly.
Jeff Terrell: It'd be fun for me to dig into some code and show you some examples of these different things, but I just don't have time and also
Jeff Terrell: You know, every project is different, which makes it hard to do that as well. But any questions about this and feel free to ask questions that are related to your project that's totally fine.
Jeff Terrell: I'll just go back to that.
Jeff Terrell: Remember that you you will be writing tests for your project. So this isn't completely, you know, in the abstract, whatever. This is something that is relevant for the semester.
Jeff Terrell: Okay, um, don't see any questions, so keep moving test coverage. This is the assignment that you'll actually do related to testing is to report on your test coverage for your project.
Jeff Terrell: And having some interpretation around whether that was a good coverage or bad coverage or on what you think about it, some analysis.
Jeff Terrell: So there's no perfect metric to measure the health of the test suite, where the health of a code base, despite what
Jeff Terrell: Maybe some people might tell you there's no such thing. And the reason for that is that it depends. It depends, for example on how you want to navigate some of these trade offs.
Jeff Terrell: As well as other trade offs and as well as other things. But that said, test coverage is a useful metric. It's one that
Jeff Terrell: At a Glance can convey a lot of useful information correlated with the health of a test suite. It's certainly not the whole picture of the health of a test suite or of a code base, but it it's a useful thing to report.
Jeff Terrell: What this is measuring is the percentage of the code base exercised by the whole test suite. And when I say test suite patches meaning like the complete collection of all of the different tests that you write
Jeff Terrell: And so you're saying like 100% test coverage means that every single line of code in the implementation is covered by a test and maybe many lines of code are covered by more than one test, but every line of code is covered
Jeff Terrell: In most cases, you're not going to pursue 100% coverage, there are projects that do a lot of them tend to be mission critical
Jeff Terrell: Maybe they have a ton of users. And so even a small bug is going to affect a lot of people, and if they have a ton of users. Maybe they have a lot of resources as well. And you can spend the time to get to 100%
Jeff Terrell: But most times in my experience, people aren't really trying to hit 100% coverage and they're just trying to get again some some confidence that what they're writing has correct it hasn't broken anything else.
Jeff Terrell: One of the reasons that hundred percent is not a goal is at some code is just boring and doesn't mean it's just there's a nice not really doing anything interesting or complex or whatever. And so
Jeff Terrell: You don't need to write tests.
Jeff Terrell: Or maybe tests just aren't worth the trouble we saw some of the trade offs of tests a little bit ago, like when not to test. And the main reason I said that you might not test in some cases.
Jeff Terrell: Is the complexity that the test adds another case might be. If you know your interfaces liable to change and you want to avoid the inertia.
Jeff Terrell: So in some of these cases, it makes sense to say, you know, I'm going to decide. I don't want to do tests at this point. And there's a good reason for it. This isn't a black and white thing.
Jeff Terrell: For you should always do this or you should never do that.
Jeff Terrell: By the way, a measure of your engineering maturity is to be able to evaluate risk and reward in light of the context of a given situation. And so the classic engineers answer to a variety of questions related to his or her craft is
Jeff Terrell: It depends.
Jeff Terrell: Which probably some joke about that I should tell that instead of just saying that anyway.
Jeff Terrell: That's, that's kind of the answer you always get from a good engineer is like you ask them a question they say, Well, it depends. And it can be frustrating for people who are trying to just get an answer. Or maybe, think, think of the world in terms that are a little bit more black and white.
Jeff Terrell: But the engineer has good reasons to say that because it actually does and and a good engineer is going to be able to articulate
Jeff Terrell: What are the factors on what things does it depend. So that's a kind of an aside, may be useful to you in your careers or whatever, maybe not, but
Jeff Terrell: Just in light of this, this idea that you're not you're not trying for 100% coverage, most of the time.
Jeff Terrell: You're making an informed choice and each case, you know, every feature that you implement is this worth testing. Isn't that worth testing. So getting good at being able to evaluate that risk and reward in light of different contexts is really a good skill to cultivate
Jeff Terrell: Related to the assignment coming up, remember that from the syllabus that an app, getting a great have a, among other things, has good test coverage, which is probably going to be over 70% although that can depend on the project.
Jeff Terrell: So, you know, if you if your test coverage report says we're only 50% but I'm persuaded that you have good reasons to only be a 50%
Jeff Terrell: That's fine, right. I'm this is part of what it means to have different projects is that
Jeff Terrell: Different projects have different contexts and different needs. And so what makes sense in one project not make sense.
Jeff Terrell: Do you just have to be able to justify that.
Jeff Terrell: Questions about the test coverage assignment or about the concepts here.
Jeff Terrell: Okay.
Jeff Terrell: Um, let me talk about a few challenges and I'm gonna I'm gonna pick on a few teams here.
Jeff Terrell: I'm
Jeff Terrell: Sorry if you wanted to be picked on, and I didn't pick on you and sorry if I picked on you and you didn't want to be
Jeff Terrell: Team i is using Tableau for their app.
Jeff Terrell: I don't really know how that works. To be completely honest with you, and I don't know what makes sense as far as the testing approach for tablet, maybe there are functions that are they're using under the scenes that do different kinds of data analysis.
Jeff Terrell: And if so, I would say, maybe you could
Jeff Terrell: Or maybe, maybe they're using some kind of coding. You could extract that into a function and add tests for those functions for those classes, whether those tests or unit tests or integration tests. I guess it depends on the code.
Jeff Terrell: But I don't even know if that's a thing or not. I don't know how much code goes behind the tablet stuff. I'm just fairly ignorant about it. So let's say for example, if there's no code.
Jeff Terrell: That maybe might not have been the best project to to do in the contract 23 projects or for for me to allow to come 523 projects. There's no code at all.
Jeff Terrell: But let's say for the sake of argument that there was no code at all. It was just a question of wiring a bunch of different things up together the right way.
Jeff Terrell: You could actually still write tests for this right. You could use Cyprus and drive a browser through the app and you could have your eta tests.
Jeff Terrell: Even in that case, right. So if you're trying to get test coverage.
Jeff Terrell: That could be a way to go. Now, one of the challenges of test coverage is that generally speaking, you're going to be relying on some relatively low level tool to be
Jeff Terrell: Observing the individual lines of code as test is executing and that can be kind of a challenge. So if you were doing. For example, testing a tablo app using Cyprus.
Jeff Terrell: It'd be a challenge to say, Okay, how many lines of code was actually covered. Well, I don't know, maybe I have to hand calculate fat or something.
Jeff Terrell: Must some tool exists that can can tell you when a line of code is being executed.
Jeff Terrell: Let me pick on team sees a team. See, is creating a VR app. This is definitely a sort of a curveball here for 523 and they're they're brave to take it on.
Jeff Terrell: So again, there, there probably is some code underneath this app. I don't really know the details at all. But I think you have to write some code to make this work.
Jeff Terrell: And so you can again extract so that code into functions or classes if it isn't already extracted in such units. And then you could write your unit tests or your integration tests to make sure that those units are doing the right thing.
Jeff Terrell: Um, what about you to eat testing on a VR app. Honestly, that's not anything I've ever looked into, but maybe maybe that's too hard. I'm imagining if if you have a VR app and and you're wanting to do either a testing that you're going to need some sort of a robot that can
Jeff Terrell: Either actually move around with the headset on or simulate moving around in a simulated Dr environment.
Jeff Terrell: The simulated part might not be hard, but then it also has to report on what does it actually see and how are you going to write an assertion.
Jeff Terrell: That something is visible on the screen at one time.
Jeff Terrell: Maybe you need machine learning and image recognition algorithms at that point to do that. That sounds pretty hard. That's starting to sound like a pretty difficult task.
Jeff Terrell: And maybe this is an area of active development in VR app writing i don't i don't know i'm just not really in tune with the space.
Jeff Terrell: But, you know, make an informed decision. Figure out what kinds of tests makes sense for your app.
Jeff Terrell: And maybe maybe teams evil decided end to end testing is not liable for their for their app.
Jeff Terrell: Alright, another example team in going to pick on team in their modernizing the data centric website. This is that open Nietzsche.
Jeff Terrell: Dig the archaeology dig happened two years ago. It has that old website and they're modernizing it
Jeff Terrell: There output like their program that they're writing for class is a program that
Jeff Terrell: parses the site as it currently exists understands the various data in the site and the relationships between different pages and elements.
Jeff Terrell: And then kind of reproduces that in a nicer way and then it's done the program runs once and then it creates a static site that can be deployed somewhere and there's no long lived state full process anywhere there's no database.
Jeff Terrell: That needs to be accessible from a back end or anything like that. So an integration test for them.
Jeff Terrell: Or sorry, an end to end test might actually be pretty easy because then the interface that they have to have a robot drive through is the command line interface which is
Jeff Terrell: Really easy to script it. That's one of the reasons the command line is so great is that it's easy. The script. So maybe end to end testing makes sense in that context, even more than unit and integration tests.
Jeff Terrell: Again figure something out. That makes sense for your projects and justify it to your teammates. If you need to, but
Jeff Terrell: You think about your project and what makes sense for it. Every project is different.
Jeff Terrell: Questions about test coverage as a sparked any thoughts that you have for how to apply this to your own project.
Jeff Terrell: Okay. No questions.
Jeff Terrell: Alright. Finally, I want to say a few words about test driven development.
Jeff Terrell: We saw that test driven development or TDD is one of the XP practices. You might remember that when we talked about agility.
Jeff Terrell: And even today, this is considered a little bit extreme. Not everybody is doing test driven development where you write the tests first before you write any code.
Jeff Terrell: In fact, I just saw a comment from a one of the mentors that said
Jeff Terrell: There are various contractors that work where he works. And a lot of them are very dedicated to the idea of at agile and agile methods and agility and DevOps and all this kind of stuff. But even they don't do TDD.
Jeff Terrell: And so yeah, this is still a little bit extreme. Even today.
Jeff Terrell: I've done this. It took me a while to get there. And I wanted to talk a little bit about kind of why it was hard for me and what some of the other great trade offs. Here are
Jeff Terrell: And let me contrast it to what I'll call to the test last development for you do your development, make sure that it works. And then as the last step before you commit you write tests that that already pass
Jeff Terrell: And your, your red green refactoring is kind of like
Jeff Terrell: Okay, I'm gonna write some some tests that like as I'm writing it, it's red, because it's not the test isn't finished. I'm not finished reading the test.
Jeff Terrell: And then once I finished writing a test and then I can be green, and maybe even after I get to green. Then I can refactor with a nicer feedback loop. I don't know.
Jeff Terrell: But, but I used to. I used to tell my colleagues with job that I worked last where everybody else was doing TDD or at least aspiring to
Jeff Terrell: And I kind of said, Well, you know what I'm going to do test last development. I actually think that works a lot better for my workflow and tried to kind of be a
Jeff Terrell: contrarian voice there maybe potentially to give other people more comfort in in not not doing TDD if they didn't feel like they could do that effectively.
Jeff Terrell: And I really thought a lot about, like, why, why do I prefer to do and what is it about it that
Jeff Terrell: feels more comfortable to me or I feel like I'm more productive because I am convinced that having tests in your code base is is necessary for any long lived code base. So I am going to write the tests, but to me it just feels more efficient to do it last rather than first
Jeff Terrell: And I realized that my main difficulty was just that I wasn't nearly as fluent in writing tests as I wasn't writing code.
Jeff Terrell: I knew how to write code had been doing that a lot but writing tests. I still felt like, okay, how do I express this again and
Jeff Terrell: What do I need to say here, and what are the different options that I can do for different assertions and I had to look up the documentation and it was just a slower process. I wasn't as fluent in
Jeff Terrell: Furthermore,
Jeff Terrell: I had my dev environment. And I knew how to use good feedback loops and so the tests gave me a good feedback loop.
Jeff Terrell: But I wasn't necessarily feeling a need for that because I already had one with my dev environment right I would
Jeff Terrell: Save something and I could quickly see the effect of that change in my dev environment. So I was getting that feedback. Anyway, even without tests telling me, whether they passed or not.
Jeff Terrell: So for me, it turned out that once I got more fluent with writing tests and I could just kind of write, write it and I knew the options and I knew things from memory.
Jeff Terrell: Then I'm often prefer to do test driven development because then I had a feedback loop. I didn't have to set up myself. And it just automatically was set to to to work and to give good feedback to me as I developed
Jeff Terrell: Note that TDD antibody are both going, they're all about providing current and future confidence again confidence is the name of the game. Do I have confidence when I'm developing
Jeff Terrell: I could have confidence because I wrote my tests first and they're giving me feedback about whether this is all going to work or not. If it's green, I trust that it really is going to work.
Jeff Terrell: But God can provide that confidence to so I can play around in the development environment and see my future working
Jeff Terrell: And then I'm still confident that I'm not breaking any existing code because everybody else has already added tests for the code, whether they did tests first or tests last last they still all exist right now for all those features that were already committed
Jeff Terrell: So again, it's all about confidence.
Jeff Terrell: Okay, looks like we're going to end a little bit early today. I'm not quite done yet. But some next time I'm probably going to talk about test doubles and how to isolate your, what would be integration tests and make them unit tests.
Jeff Terrell: And I'll also give some tips for test friendly code. How do you write your code in such a way that you can easily test it and get your test coverage numbers higher
Jeff Terrell: This is something that I've actually worked with already for one of the one of the teams in the class has said, Okay, I don't know how to write tests for this. And so I worked with them in the app lab. Remember the app that exists.
Jeff Terrell: And that was, that was really helpful. But I wanted to kind of capture that and also share it with the rest of the class as well.
Jeff Terrell: I'm going to try to cover tech debt. We'll see how much time we have, but this is an important topic that comes up in the context of software engineering
Jeff Terrell: I originally was hoping to also get to authentication this semester. And it looks like I'm not going to get into that because Wednesday is actually the last time I'll be lecturing the semester.
Jeff Terrell: And I will also need to provide enough time to do our final quiz. And remember that that will include the content that I cover on Wednesday.
Jeff Terrell: I have some
Jeff Terrell: Takeaway questions. But before I do, I'll pause. One more time for any questions about testing, anything that we covered today.
Jeff Terrell: Okay.
Jeff Terrell: Well, I'm gonna open up the takeaway questions here in just a second. And let me also save that.
Jeff Terrell: I'll stick around for a few minutes. If you had further questions or wanted to talk to me more like
Jeff Terrell: Not in front of everybody, but maybe in front of a smaller audience after people have left or whatever. I'll be around for a few minutes after I open this up.
Jeff Terrell: And yeah, looks like we're stopping about five minutes early today. So when you finish this whole you can you can go. All right, I'm gonna activate the quiz now.