Jeff Terrell: Alright let's get started.
Jeff Terrell: Hope everybody's doing all right i'll get a good.
Jeff Terrell: day off yesterday and we able to maybe rest up a little bit.
Jeff Terrell: Today we're going to talk about testing and a few other things, a couple of announcements, first, I decided to only allow Google slides for the midterm presentations just because I think that'll make it a lot easier and faster to transition between.
Jeff Terrell: Different presenters we're going to try to move pretty fast during the mid term presentations so if that is a problem for somebody feel free to let me know we can try to accommodate that but but i'm hoping that won't be a problem for anybody and that'll help us move faster.
Jeff Terrell: If you're not able to show up in person for the midterm presentations next week, please let me know sooner rather than later we'll we'll try to accommodate you I heard from one person already.
Jeff Terrell: But yeah let me know that soon.
Jeff Terrell: So, after the walking skeleton walking skeleton is really a pretty pivotal assignment it's also a pretty big assignment, but things will change a little bit after the walking skeleton there will still be occasionally assignments do most of these assignments, are going to be pretty light.
Jeff Terrell: And there'll be important, but they're not going to be really involved in the in the development of actual features.
Jeff Terrell: And I can't really have assignments about the features per se, just because every project is different, but what I do want from each team is to have DEMO videos.
Jeff Terrell: Showing demonstrating the features that you completed in a given week and those will start to be do the week after the walking skeleton so the walking skeleton is do Monday DEMO videos will be do each week after Monday so.
Jeff Terrell: A week from Monday to extra Monday three extra Monday, etc.
Jeff Terrell: And those will be posted on your website in your journal section.
Jeff Terrell: And Raj will be grading those as well as any assignments that are two week to week there's a.
Jeff Terrell: On the assignments page I added a paragraph about this and there's a page that talks more about DEMO videos and what to expect so there's a few tips for how to record these videos.
Jeff Terrell: How to deploy things so that you can actually DEMO that deployed features and so on, so feel free to check that out.
Jeff Terrell: Questions about this.
Jeff Terrell: Okay.
Jeff Terrell: And we will do quiz for today, at the end of class so i'll save some time for that.
Jeff Terrell: Just a couple more things I wanted to talk about with agile practices, I didn't quite get to everything that I thought was important to cover so that I think three more slides on that and then we'll dig into testing.
Jeff Terrell: We were in the middle of talking about our.
Jeff Terrell: 10 practices for for agile methods.
Jeff Terrell: And some of those are coming from xp some of them are not.
Jeff Terrell: xp I believe talks about planning game, and this is kind of the same idea here, but the idea is just being able to estimate how long things are going to take that's actually a really useful thing to to do for your client remember I talked about the idea that maybe the client might.
Jeff Terrell: They might have one feature that's really the most important that they really like, but once they understand that that one feature is going to take as much time as the next five features they might decide actually the next five features are more valuable than just this one so.
Jeff Terrell: Having some input on that some ability to see kind of how much effort is expected is a really useful thing for a client to determine priorities.
Jeff Terrell: And this is not easy to.
Do.
Jeff Terrell: Sorry, getting some.
Jeff Terrell: Some noise here.
Jeff Terrell: and Alexander if you did have a question feel free to interrupt me but um.
Jeff Terrell: yeah, this is not easy to do, but this is something that you can get better at.
Jeff Terrell: And what I would recommend, if you would like to do this and get better at it is make a guess about how long things will take.
Jeff Terrell: And then get some feedback on that guess right measure how long it actually took and then compare actual time versus estimated time and that'll help you calibrate to get a sense of how long things take.
Jeff Terrell: And this is not something that probably you will ever perfect just because predicting the future is is hard.
Jeff Terrell: predicting the future accurately every time is probably impossible.
Jeff Terrell: But you can get better at it, if you if you work at it.
Jeff Terrell: there's also this useful idea called capacity capacity for your team so once you start estimating tasks, you can get a sense of how much your team can tackle in a given iteration.
Jeff Terrell: Maybe they can maybe you estimate 20 hours of work and.
Jeff Terrell: And it turned out that you were only able to get to 15 hours of that work over the course of the iteration so, then you could say, well, I guess, my capacity is 15.
Jeff Terrell: And maybe the next iteration you say we think we can get this 15 hours of work done, but it turns out, you actually got a little bit more done got to 818 hours.
Jeff Terrell: And that can just inform over time, like what our current level of estimated capacity is going to be so that the client can have a sense of what to expect at the next iteration meeting.
Jeff Terrell: One of the thing about estimation, is that you can be a little bit more precise on the low end of the spectrum, as far as how long these tasks take.
Jeff Terrell: It makes less sense to be super precise when you're talking about like more than eight hours of work.
Jeff Terrell: So typically you might break this down into like maybe one hour to hour for hour eight hour 16 hour tasks that you wouldn't say, for example, like this is a 13 hour task if you think it might be 13 you probably.
Jeff Terrell: might as well around that up to 16 or maybe if you really think you get it done in a rounded down to eight, but your ability to estimate that many hours or that that big of a chunk of work.
Jeff Terrell: Probably won't be able to do that very precisely so so you need to kind of round to the nearest big number.
Jeff Terrell: Or maybe better idea is to break something big down into smaller tasks, if you can, and then you can estimate those and maybe have a little bit more confidence in your overall estimate.
Jeff Terrell: Okay topic two of three that I didn't cover last time on agile practices con bond anybody heard the term con bond before so something y'all have heard some of you okay.
Jeff Terrell: Some of you may have seen this and internships and things like that.
Jeff Terrell: Okay, somebody online and seen it yep so.
Jeff Terrell: This is actually Japanese for like signboard or billboard it originated in Japan at Toyota.
Jeff Terrell: The idea is that every piece of work is represented by a card and stages of work are represented by columns on this board Okay, and so the cards flow from left to right across the board, as they go from one stage to work to the next.
Jeff Terrell: sound familiar.
Jeff Terrell: it's basically what we do with trailer if you're using trailer for project management same thing.
Jeff Terrell: Hello and other tools have a sort of combine you know visual board metaphor and cello is designed so that the columns are pretty important to just the overall interface with cello so.
Jeff Terrell: To try, though, and other tools are definitely they use the idea of con bond.
Jeff Terrell: Now there's a couple things about con bond that probably a lot of people don't do even like if you if you interview with somebody and they say they do con bond.
Jeff Terrell: ask him some of these questions like do you do this, do you do, that they might be pretty impressed with your knowledge about con bond.
Jeff Terrell: Strict con bond would mean that cards never go from right to left they only go from left to right and if a card turns out not to be needed anymore, well, it just goes to done that work is done.
Jeff Terrell: Even though even maybe you didn't deploy anything that the card represents the work and the work is not done.
Jeff Terrell: Or if maybe you think a card is done, but some changes are requested from the client those changes need to be captured in a new card because that's new work right that new work starts at the beginning and has to go through all the stages of work, just like everything else.
Jeff Terrell: And so that would be one aspect of strict con bond that I actually have not ever used in a project i've done con bond style projects before but i've never been the strict about it, no place i've worked has been a strict about it.
Jeff Terrell: Another thing about strict combine is that you, you have limits on how many cars can be in a given column, at a time.
Jeff Terrell: So you say like well in the in progress column, we can only have four cards and progress at a time.
Jeff Terrell: And what this means is that if you're if there are already four cards in progress.
Jeff Terrell: And you're wanting to create another like to start another one and move it to in progress, you can't do that you need to go figure out something else to do to start to clear out some of the stuff that's in progress and make room, so that you can start something new.
Jeff Terrell: And the idea for that actually makes some sense is you want to limit the total amount of work that's in progress somewhere between like the start column, and the end column.
Jeff Terrell: limit the amount of work that's in between, because the more work that's in between the more distracted you'll be for what you're actually working on.
Jeff Terrell: And the more context switching you'll have to do between all the different things that are in progress and context switching wastes time.
Jeff Terrell: So, to the extent you can limit the work in progress and the way con bond does this is by having rules about the limit of how many cards can be in a given column, at a time.
Jeff Terrell: You might have different limits for different columns, by the way, but still.
Jeff Terrell: So yeah maybe you'll impress somebody by asking that and then interview you say you to combine but.
Jeff Terrell: Another term that you may have seen on I don't know job advertisements or something like that, or maybe you've seen it in industry or use it on a project is scrum I mentioned it last time.
Jeff Terrell: Broadly kind of similar to xp con bond scrum xp and other things are kind of broadly within this realm of agile methods for agile software development.
Jeff Terrell: I mentioned kind of my quibble of scrum last time, is that they like to use the word sprint or I think the more appropriate term would be iteration I dislike the idea of always sprinting and scrum kind of implicitly.
Jeff Terrell: implicitly endorses that by calling them sprints every week or every two weeks as a sprint.
Jeff Terrell: Anyway, that's just a quibble I think scrum is fine.
Jeff Terrell: One of the defining characteristics of scrum is the scrum meeting.
Jeff Terrell: And this is also called like a stand up the idea is that you just get together daily with your team usually early in the day, maybe, maybe first thing in the morning.
Jeff Terrell: And you just have a really brief meeting, where each person says what did I do yesterday, what am I planning on doing today.
Jeff Terrell: And is there anything that everybody should know or am I going to need help with something or Do I need something else to be finished before.
Jeff Terrell: I do, what I do you know, do I see any obstacles to me or the team achieving the goals so it's just three questions usually the answer to the third question is is no or you just don't even mention it if you don't see any obstacles.
Jeff Terrell: And I mean this goes fast right it's just real brief check in and that's actually why I caught a stand up, is that the idea is that the meeting needs to be short enough that everybody could stand up for the entire meeting without I don't know without any difficulty.
Jeff Terrell: So i've been in stand ups, where there's been as many as 10 or 15 people around the table checking in and even those are pretty quick.
Jeff Terrell: It really doesn't take long, let alone if there's just you know if it's just the three of you on your team, the three to four of your on your team doing a check in.
Jeff Terrell: This could be you know, a minute long minute or two really doesn't have to be long, but it is a chance just for everybody to sync up about the work that's going to be done today.
Jeff Terrell: Actually, when I worked at the company, I worked at before I came to you and see we did check ins asynchronously over slack everybody just had a just going to answer these three questions.
Jeff Terrell: And just did it over slack and it wasn't even a synchronous meeting it was just you know when you start work post to the check and channel.
Jeff Terrell: But that's kind of the defining characteristic of scrum there are differences between scrum and xp but i'm not going to cover all those here broadly it's pretty similar.
Jeff Terrell: So any questions about con bond scrum or estimation.
Jeff Terrell: If not we'll move on to testing.
Jeff Terrell: Okay.
Jeff Terrell: Okay, so let's let's switch gears here.
Jeff Terrell: So imagine after the Semester finishes.
Jeff Terrell: The client needs some bug fixed or some feature added but you've already graduated you've moved on me he didn't really intend to come back to your 523 project that's in the rearview mirror at this point, you move to some location you work for some awesome company.
Jeff Terrell: And the client they heard their niece has a friend who knows how to code.
Jeff Terrell: So that friend could get access to the code base right and maybe start to make changes, but how will the friend learn the code base and feel confident about what they're doing.
Jeff Terrell: How will they know what the APP is supposed to do and whether anything broke.
Jeff Terrell: We talked about this a little bit last time.
Jeff Terrell: You might remember kind of the direction that i'm headed here.
Jeff Terrell: or, for that matter, you you move to some location work for some awesome company, now that you've graduated.
Jeff Terrell: And you get to work, and you have your first assignment, you have to add some feature to the big flagship half of this company, how can you learn the code base and feel confident about your changes.
Jeff Terrell: feel confident that you're not breaking something when you start to change the code.
Jeff Terrell: In general this kind of thing is called quality assurance.
Jeff Terrell: How do you assure that the code is of good quality and at the APP is of good quality.
Jeff Terrell: And there's a few different approaches to this one is you can test your changes manually and just trust that everything else still works.
Jeff Terrell: All right, because you don't really know what all the other features are supposed to be like, if you wanted to actually learn the entire APP This is like the flagship APP of a of a big company and.
Jeff Terrell: there's a lot of stuff in it, it would take you some time to learn the expectations of exactly what this APP should do and how it should work in various you know circumstances.
Jeff Terrell: So you just test your stuff you learn a little bit about what your section of the code that you're contributing to is supposed to do and you make the changes that you think are going to work and then you just test that right you just test it manually in your development environment.
Jeff Terrell: But, did you consider all the possibilities.
Jeff Terrell: Did you really think about.
Jeff Terrell: All the different things that can happen and all the different error cases there might be, I mean you know, there might be some some bugs hiding in the corners of the APP that you didn't consider.
Jeff Terrell: Did you test all browsers if you have a browser APP a web APP you know did it work in chrome but not in firefox or non safari or something like that.
Jeff Terrell: Did you consider that maybe the user requesting this page might not be authenticated or perhaps they might not be authorized to see that page, even if they are authenticated.
Jeff Terrell: Did you test that Do you remember to test that.
Jeff Terrell: So you can see, like that this is kind of an error prone process, you might not remember to test all the possibilities, you might not even know of some of the possibilities, did you even realize that the back end could return a I don't know a tool for response.
Jeff Terrell: And so, so that that is an approach that some people will do, but it does it does have some problems.
Jeff Terrell: Now some companies kind of got smart about this and they'll create like a testing script like a manual scripts like.
Jeff Terrell: Do this then do that then do this and you should see this and you should see that and then do this and click on this button and some human has actually walking through the APP and doing all these things in this testing script.
Jeff Terrell: This this isn't a fun thing to do right if you're if you're a developer you'd rather be writing code then walking through the testing script for the 15th time.
Jeff Terrell: So when it's time to do that it'll be really tempting to cut corners, it feels like a waste of time it's tedious it's not fun it'd be like add this part of the APP is going to work i'm not going to do all that part of the testing script.
Jeff Terrell: And so, for that reason, it can be error prone right, you might skip something that actually there was a bug and that you skipped it and even if you're doing it.
Jeff Terrell: Even if you're being diligent trying to do it, you might miss a step or make a mistake as you're following the script.
Jeff Terrell: So it is error prone.
Jeff Terrell: And attends to make releases infrequent right if you are, if you have this manual testing scripts that takes half an hour to do you're not really going to want to be releasing all that often because every time you do, you have to walk through this script and be like.
Jeff Terrell: I don't know let's just batch up a bunch of changes walk through the testing script once it's more efficient that way.
Jeff Terrell: and your releases are infrequent you remember what I talked about earlier about having frequent releases is you know system agility helps you compete in the marketplace tends to be more fun work this definitely is intention with that idea.
Jeff Terrell: After I graduated with my PhD from this department, I was doing some freelance work and I worked at a company that had a manual testing scripts just kind of a small a small shop.
Jeff Terrell: They just had one product they were working on, and I remember going through kind of the pain of this like you know it's actually kind of interesting, the first few times I did it just seeing all the steps and.
Jeff Terrell: learning about the APP and learning about things I didn't know the APP could do that to see sections of the APP that I just hadn't really seen before.
Jeff Terrell: But after i've done it half a dozen times it's like I have to do this again and, of course, we wouldn't release all that often and it just seemed like a waste of time, every time we had to do it.
Jeff Terrell: Depending on the maturity of the company, they might even have a separate QA team.
Jeff Terrell: So there might be like the Dev team, the OPS team and the QA team QA team might just be testing the APP all day every day.
Jeff Terrell: which I mean, I guess, maybe some people would like that sounds awful to me, but maybe some people would really enjoy doing that trying to find bugs and things like that, but, but you still have some of the same problems.
Jeff Terrell: tend to make releases and frequent, it can be error prone so anyway, all of these leaves something to be desired.
Jeff Terrell: As you may have anticipated based on last lecture where i'm headed with this is that the gold standard for quality assurance is an APP with automated tests.
Jeff Terrell: covering all of the important features, so if your tests are automated you've eliminated the tedium because the computers doing it not you it's not error prone anymore, because the computer is doing it not you.
Jeff Terrell: And if you have a good test suite that it's covering all the important features and is reasonably fast it can actually be a real help to development, you can start to get into this creative flow as we'll talk about minute.
Jeff Terrell: So automated tests are a really nice thing the technology for this is improved greatly over the past probably 10 or 20 years.
Jeff Terrell: It used to be pretty cutting edge you, you had to invent a lot of the infrastructure to do this yourself if you want to do it 20 years ago, but these days there's a lot of things that make this really easy.
Jeff Terrell: So back to our story you've graduated you've moved to work at some awesome company, you have to add some feature to the flagship APP.
Jeff Terrell: On the first day you got a Dev environment setup you just follow the instructions and the Read me so you're able to have an isolated Dev environment that doesn't affect anybody else and helps you feel confident that you're not breaking any of your teammates.
Jeff Terrell: And you know you, you know get at this point fairly well so you're not too concerned about.
Jeff Terrell: Making some change that you can't undo because if you need to you can always use kit to just you know reset hard and get rid of your changes or figure out exactly what changed and that lends to confidence helps you feel more courageous taking this on.
Jeff Terrell: But also, you know this APP has a comprehensive automated test suite and so you can make some changes run that test suite and figure out did you break anything so that really helps you feel confident that you're not going to break anything if you did you'll find out.
Jeff Terrell: In fact policy of the company is that you can't even deploy anything unless all the tests pass.
Jeff Terrell: and ideally your commit won't be accepted your you know your pull request won't be merged if you didn't add good test coverage for the future that you add it so it's a way to just kind of keep the test suite healthy Keep it up to date.
Jeff Terrell: So that's a that's a nicer story.
Jeff Terrell: Now there are some alternatives to testing besides kind of some the manual process that I talked about earlier with quality assurance.
Jeff Terrell: there's a bit of a debate in different programming language communities, about the value of tests versus the value of types and some people would say that types are more valuable in tests, especially if you have a fairly sophisticated type system.
Jeff Terrell: Some of these type systems can really catch a lot of different kinds of bugs at compile time before you deploy so that can be pretty useful.
Jeff Terrell: typescript is actually not bad, but you get into something like haskell and that that gets really sophisticated a nice.
Jeff Terrell: Pretty big learning curve, I still haven't really learned haskell but.
Jeff Terrell: Anyway, if you're curious about type systems, by the way, I will be covering that in my 524 class next semester if anybody's interested in that.
Jeff Terrell: But even code bases that are written in haskell or or ssl or something like that are often still going to have some amount of tests, just to add some confidence because there are types of bugs that tests can't catch even with our sorry that types can't catch even with sophisticated.
Jeff Terrell: Type systems and, in fact, there are some types of bugs the tests aren't going to catch either so neither one of these is any sort of a guarantee that what you what your APP is going to be bug free but both of them can catch catch some things and can help.
Jeff Terrell: Questions so far.
Jeff Terrell: Okay.
Jeff Terrell: So, for the rest of the lecture i'm going to talk about why we would test, what are the reasons to actually have tested at this point i'm assuming automated tests not manual tests.
Jeff Terrell: want to talk about some reasons not to test.
Jeff Terrell: types of tests, there are different kinds.
Jeff Terrell: And then briefly i'll talk about test coverage and when to write tests.
Jeff Terrell: Six reasons to test.
Jeff Terrell: First, reason and the most important reason tests give confidence.
Jeff Terrell: So as i've been discussing up to this point if you have a good test suite in place, then you will be a lot more confident as a developer, that you are adding good code and not breaking existing features.
Jeff Terrell: Breaking an existing future, by the way, is called a regression So if you ever see that term it's not a linear regression and in math or stats it's a encode it's when you break something that used to work.
Jeff Terrell: it's like moving backwards.
Jeff Terrell: i'm remember and xp we talked about courage, courage is one of the values of xp and tests are a major thing that can enable courage.
Jeff Terrell: And this really is the most important reason to write tests just having that confidence being able to just dive right into the code start making changes see what works what doesn't work get some feedback from your tests.
Jeff Terrell: and not to be in this stuck state or this hesitating state where you're like.
Jeff Terrell: I don't know what did I need to do what if it breaks something i'm not sure what to do first but being able, just to jump right in and get things done is is important that's courage and that's what tests can give you.
Jeff Terrell: is the most important reason, in my opinion.
Jeff Terrell: Reason number two, I would say, so you get the perspective of the collar and this helps you keep things simple remember that's xp value, what is the number two maybe.
Jeff Terrell: Anyway, simplicity right you want the code to be as simple as it can be, and if you are testing, especially if you write your tests first.
Jeff Terrell: Then you're testing the interface of some code that you're about to write and you're only going to write the code that needs to make the tests pass and so that tends to keep things simple and focused rather than getting over engineered.
Jeff Terrell: And remember the acronym gagne you ain't gonna need it just do what you need to do, write a simple test that can you know if you can pass this test then your stuff works and right only the code, you need to to make the test pass and that will keep things simple.
Jeff Terrell: tests can also be useful to document developer intentions.
Jeff Terrell: You could have a high degree of discipline about your code.
Jeff Terrell: and have documentation for every function and method, and there are conventions of doing us in comments and some code bases they're going to want you to do this and there is some value there right, if you want to generate API documentation for others to see, then, that can be useful, but.
Jeff Terrell: Probably for most projects in this class at least you don't need that level of documentation.
Jeff Terrell: And it's easy just to look at the tests to figure out what kinds of arguments this function can support or how your intended to use this class, you can just look up the test and see how the test uses it.
Jeff Terrell: fourth reason is tests close the time gap.
Jeff Terrell: Regardless of how you program whether you use tests, a lot or not, or whether you test first or test last.
Jeff Terrell: If you really are a good programmer you're going to be using feedback loops pretty extensively you're going to have a way of.
Jeff Terrell: Getting feedback about some change that you just made to see is this right or not, and if it isn't what's wrong with it and tests are a pretty natural way to do this.
Jeff Terrell: I can really help you focus in on what you're trying to do.
Jeff Terrell: and help you.
Jeff Terrell: Get just get into that creative flow state which actually i'll talk about in a minute as well, but.
Jeff Terrell: If you have a test suite that's fast.
Jeff Terrell: Or, if you are.
Jeff Terrell: If you have a test suite that can be sort of focused in on what you're actually changing.
Jeff Terrell: Then you can have a fast feedback loop and iterate very quickly on it, you make some change and you instantly get feedback I talked about this last time.
Jeff Terrell: And then you're not waiting at all you're not getting distracted as you're waiting you're just getting instant feedback, so you can stay focused and keep moving.
Jeff Terrell: So if you have rapid tests that enables you to have rapid iteration towards working features.
Jeff Terrell: If your test tells you something broke, it was in the code that you just changed and saved and probably that's a fairly small set of changes that you could undo pretty quickly.
Jeff Terrell: But if it passed, then you can forget about all those changes and move on to the next thing and just stay tightly focused.
Jeff Terrell: And even if you don't have rapid tests slow tests are going to help you find bugs a lot faster than just waiting for users to send out a bug report.
Jeff Terrell: Alright, fifth reason to test is that tests enable refactoring and refactoring again is coupled with this xp idea of simplicity, keeping the code simple.
Jeff Terrell: And in test driven development remember xp talks about red green refactor refactor is that third step to spend some time making it simple not just making it working.
Jeff Terrell: So this refactoring lets you kind of divide and conquer on the overall task of development, you don't have to try to write simple code, from the start.
Jeff Terrell: Maybe you're not quite sure how simple code would be in this case, so you can divide and conquer on that just write working code to start with, and then clean it up as a second step.
Jeff Terrell: And tests really make that easier because you wrote your tests, then you wrote your working code and as you're improving your working Code into something that's simple your tests are giving feedback, the whole time is this still correct is still correct is still correct.
Jeff Terrell: When I was working on my dissertation.
Jeff Terrell: dissertations are.
Jeff Terrell: Just a mountain of work that's not fun that was very much did not enjoy working on my dissertation.
Jeff Terrell: same with any sort of book or big written material like that, so my advisor at the time john Smith told me.
Jeff Terrell: Brain dump everything that's in your head just get it out into your editor into your files or whatever and don't underestimate your ability to revise later and that advice saved my bacon.
Jeff Terrell: really helped me not just sit sit in front of a screen stock.
Jeff Terrell: I just dumped everything that was in my head out to the screen and then I started organizing it and cleaning it up and revising and it turned into something that was actually pretty good.
Jeff Terrell: So same thing with this refactoring idea.
Jeff Terrell: Hemingway has a take on this also, by the way, says right drunk edit sober.
Jeff Terrell: And that was that was having way.
Jeff Terrell: But yeah refactoring so tests really help you refactor and make sure that all these little changes that you're making to your code are still correct.
Jeff Terrell: Final tests final reason to test is that testing can be fun testing can make coding fun.
Jeff Terrell: If you're taking small steps and making steady progress that feels good you feel like you have traction on this problem that you're trying to solve, and maybe it feels like a big problem at first, but once you start.
Jeff Terrell: Focusing in on just one small step at a time and then you get that behind you and you take that step, and you take the next one, and the next one, and you can feel the progress that feels fun.
Jeff Terrell: And it also helps like I keep talking about this idea of creative flow and if you haven't experienced that maybe maybe one day you'll notice that you're in it, but it's really almost like addictive just fun.
Jeff Terrell: fun stuff to just feel like i'm able to express my will into the system and it works it's really cool.
Jeff Terrell: kind of lose track of time, sometimes because you're just having fun.
Jeff Terrell: I think one of the worst things about programming is the opposite experience when you're feeling stuck that's usually not very fun and tests help you not get stuck because they're going to give you some feedback from the system about what is it that's broken.
Jeff Terrell: And it's not going to prevent you from getting stuck, but it will make it harder to get stuck and just overall increase, I think the enjoyment of the development experience.
Jeff Terrell: it's not a small thing.
Jeff Terrell: So the summary of why the test is here, most important thing tests gift confidence you get the perspective of the collar so you can keep things simple.
Jeff Terrell: Tests document developer intentions, they close the time gap.
Jeff Terrell: They enable refactoring and they help you have fun, while developing any questions about why we test.
Jeff Terrell: Okay, why why wouldn't we test, there are projects where I would say, I would not recommend testing for this project.
Jeff Terrell: Why would we test or not test.
Jeff Terrell: First reason not to test would be just recognizing that testing does take time and it does add complexity to your project.
Jeff Terrell: In fact, sometimes I think it's probably fairly common for tests there to be about as much Code as the actual implementation is.
Jeff Terrell: So, in a way of measuring it you've basically doubled your work to add test at automated tests and that's not nothing you know it's important this to stop and think about is this worth it.
Jeff Terrell: there's no nothing I could say about software engineering that's always always true and automated tests are included in that.
Jeff Terrell: it's not always the case that you should do automated testing, you need to be able to evaluate the pros and cons and make a decision that makes sense in that context.
Jeff Terrell: One thing I will know is that this extra complexity that tests provide is usually not as visible from your code like it's often in some other tests directory and so it's not.
Jeff Terrell: visually in the in the way of what you're trying to do so that's helpful, but it is more work that you have to do.
Jeff Terrell: Also intention with this a little bit is that if you do add tests, as I mentioned, it can help your code be simpler and so that can help.
Jeff Terrell: Make testing more worth it, because it's not like you have double the amount of code necessarily the code that you have is simpler and so maybe you have something less than double the code.
Jeff Terrell: And, as I said before, tests don't catch every bug that's no guarantee it's not a silver bullet so don't expect that it will.
Jeff Terrell: But it does catch, many of them and the feedback loop and creative flow the tests provide are useful.
Jeff Terrell: test set inertia, to the interface, and I don't mean the user interface here but, just like the function names and parameters and things like that that you have in some module or some class.
Jeff Terrell: And if you need the tests are using that interface, and so, if you need to change the interface for some reason, then, that can be a slower change that it would have been otherwise, because now it's not just the interface, you have to change it's also the tests.
Jeff Terrell: And refactoring is technically when you're just changing the behavior without changing the.
Jeff Terrell: Sorry, I said that backwards, changing the implementation without changing the behaviors and so sometimes when you're changing the interface, that would be considered changing the behaviors and that can be.
Jeff Terrell: You know, maybe not refactoring exactly but a heavier change.
Jeff Terrell: And so, generally, if you have tests, you want to avoid changing the interface, but if there really is a simpler way to go, a simpler interface then then yeah maybe it's worth it, simplicity is valuable.
Jeff Terrell: So balancing the pros against the cons my rule of thumb for testing about whether to add automated tests to a project or not is.
Jeff Terrell: If you're working on throwaway code or a short lived experiment or exploration don't test but otherwise do test anything that's longer lyft code tests are useful, and that includes all of your projects, so I would definitely recommend you all test your code use automated tests, in fact.
Jeff Terrell: You have to test to get full credit on your project grade so keep that in mind there'll be a test coverage report later in the Semester.
Jeff Terrell: Okay next we'll talk about types of tests, but before we do that let's do a quick poll, how are you feeling about the walking skeleton at this point.
Jeff Terrell: i'm guessing that deadline is looming, and I wonder if people are stressed or not just wanted to kind of check in.
Jeff Terrell: Okay.
Jeff Terrell: Few people are feeling great.
Jeff Terrell: Summer feeling good most of you are feeling somewhere in between so so all right, and some of you are feeling not good, and some of you are really maybe stressed out about this sorry if that's you.
Jeff Terrell: As i've said before, I do hope that none of this work is wasted, none of this pain is wasted.
Jeff Terrell: If you're stressed out this is stress that you're feeling now that you won't feel later in the Semester, because after the walking skeleton everything will be integrated and you'll have a deployment story and it'll be relatively smooth sailing from this point on, so.
Jeff Terrell: yeah anyway, I hope you find it worthwhile in the end, but i'm sorry if you are stressed out about that.
Okay.
Jeff Terrell: Alright, so there are different kinds of tests.
Jeff Terrell: And I want to talk about what these different kinds are so that we can talk about when you would use one over the other.
Jeff Terrell: unit tests are going to test one component in isolation, one unit.
Jeff Terrell: One unit might be a function or a class but it's something that's kind of an invisible piece of code and divisible piece of functionality.
Jeff Terrell: and integration tests this when you're testing several components are several units working together.
Jeff Terrell: So maybe you have one function that calls another function.
Jeff Terrell: And if you test that first function and just let it call the second function, then you're testing that's technically an integration test, even though it's just two units you're testing that the one component is integrated correctly, with the second component.
Jeff Terrell: Integration tests might actually be more than two it might be like hundreds of units all integrated together and you're testing all of the integration there.
Jeff Terrell: But in any case that's kind of the the difference unit as a single unit integration is more than one there's also a special kind of integration test called an end to end test or a T test.
Jeff Terrell: E to e.
Jeff Terrell: And this is stepping outside of your application and viewing it as a user does.
Jeff Terrell: Looking at the user interface that a user would actually see and having some sort of a robot that can interact with that user interface completely outside of the APP itself.
Jeff Terrell: So you're not you know the end to end test is not going to have knowledge usually have any function names or code or parameters or classes, or anything at that level it's going to be looking at the screen that's presented to users and interacting with that screen.
Jeff Terrell: So let me dig into each one of these just a little bit more.
Jeff Terrell: So yeah unit test you're assessing one component in isolation.
Jeff Terrell: There is a thing called a test double, and this is when you have a function that's calling another function, you can actually.
Jeff Terrell: instead of letting a call it at a function, you can jump in the middle and say no i'm going to give you a double i'm going to give you basically a fake version of this dependent dependent.
Jeff Terrell: dependent function depending function anyway, a fake version of this dependency, so that you're not actually calling it you're just interacting with this fake thing that I give you.
Jeff Terrell: And then you can test this function even or cause another function, you can test it in isolation, so that can be a unit test.
Jeff Terrell: The simplest thing that you can possibly test is a pure function.
Jeff Terrell: That doesn't depend on any other functions.
Jeff Terrell: And that's just testing the interface of the function did did these arguments, result in this return value.
Jeff Terrell: And there's no because it's a pure function there's no effects to tests there's no context that you need to set up for it to work you just call it see what it returns.
Jeff Terrell: that's really simple so, for example, if you had a function, which would be kind of stupid to just add two numbers together, then your unit tests could basically be if I call add with a and seven as arguments I should get 15 back and that's your unit test.
Jeff Terrell: Usually you wouldn't express it quite this way you might need something more than just an arrow maybe not depends.
Jeff Terrell: And object oriented programming if you're testing a unit of a class name csv data, you can just pass the data and directly let's assume that this class supports that and test the columns method of it and expect that the resulting value should be that.
Jeff Terrell: Okay, so that'd be an example of a unit test for a class.
Jeff Terrell: The idea of unit tests makes sense.
Jeff Terrell: yeah the key here is that these are single units in isolation integration tests are the opposite there at least two and really arbitrarily many units working together.
Jeff Terrell: And the unit doesn't just have to be like a modular function that can also be like external resources, like, for example in this in this example, this is assuming that some file exists in your file system called data that csv.
Jeff Terrell: And so, this is integrating csv data file against your your file system, and so you have to set up some context for that test to actually work effectively right, you might need to create this file, so that this test works correctly.
Jeff Terrell: Another example trying to log into the back end with invalid credentials should result in a four or three forbidden response you're probably going to have to.
Jeff Terrell: Call some back end handler you might even have to send a network request and that back end is probably going to do call a variety of functions to actually end up.
Jeff Terrell: computing the results of the flora three response and so that'd be an integration test, because you probably have a lot of different pieces interacting in order to return that for three response.
Jeff Terrell: So that makes sense integration tests.
Jeff Terrell: yeah okay.
Jeff Terrell: end to end tests again just testing the entire system as a user would see it.
Jeff Terrell: This is a kind of integration tests it's basically integrating all of your components together from top to bottom.
Jeff Terrell: So it's kind of the extreme integration tests, where where you're integrating everything.
Jeff Terrell: Typically you're going to have to have some sort of a fancy tool to navigate a user interface the counter example, might be, if your APP is just a command line APP then maybe you would not need anything fancy to actually use it as a user, would you just.
Jeff Terrell: issue a command and look to see what sort of outputs you get from that command.
Jeff Terrell: But most of the time you're going to need some sort of tool to do this and a good example of this would be Cypress.
Jeff Terrell: Cypress is a javascript library to let you do testing of web Apps.
Jeff Terrell: And in Cyprus, I actually have this working on a.
Jeff Terrell: Much time do I have, I have it working on a tool Smith project this semester, and if I have some time i'll show you what it looks like but it's pretty neat it actually just.
Jeff Terrell: opens up a browser and according to the script that you write it'll actually click the buttons and fill the forms out and it'll say I expect to see this here at this point, I expect to see that click here.
Jeff Terrell: And you can actually watch it watch it do all these things and use your APP it's pretty neat if something doesn't some assertion doesn't hold then it'll tell you okay I expected there to be a button here, but there was that it'll show you a screenshot of what it saw instead.
Jeff Terrell: yeah that's something that you need some sort of a fancy tool to actually do site versus a good one for web testing.
Jeff Terrell: And let's talk about why you would write one type of tests, instead of another or what the pros and cons are of the various.
Jeff Terrell: Testing types.
Jeff Terrell: If you have a pure isolated unit, in other words a maybe a function that doesn't depend on any other function, this is rare it's rare for function, not to depend on anything else, but it does happen, sometimes like you have some utility functions or some sort of a utility class.
Jeff Terrell: But if you have that and it's pure in the sense that it doesn't create any effects or depend on any context, other than its arguments.
Jeff Terrell: Then again, you just test the interface you call it with certain arguments you expect there to be some return value and that's all So those are really simple tests to write those would be considered unit tests, because you're only testing one unit.
Jeff Terrell: And that that's kind of the easiest possible case for testing.
Jeff Terrell: When units are pure but not isolated, this is where you have a choice about whether to use a test double or not.
Jeff Terrell: So if you use a test double for the dependency and you interpret that test double in between, so that you're actually just using the testable instead of the actual dependency.
Jeff Terrell: Then, that can be a unit test.
Jeff Terrell: Or you could just write an integration tests and let it call whatever it needs to call, and that would be the integration test and the integration tests might actually be the easiest.
Jeff Terrell: When the units are neither pure nor isolated that's when things get trickier that's when you have to start thinking about what the effects are going to be, or what sort of global context might be, you might need to set up beforehand and i'll talk more about that later.
Jeff Terrell: unit tests tend to be faster there tends to be less code involved that needs to be executed for a given test because you're just testing a single unit.
Jeff Terrell: And I mentioned related to test doubles this is kind of important.
Jeff Terrell: They assume but don't test.
Jeff Terrell: That as calling me correctly and that be really does return what it says it needs to return or what the text says it's going to return.
Jeff Terrell: So when you have that testable you're you're not actually calling.
Jeff Terrell: Be from a.
Jeff Terrell: you're.
Jeff Terrell: kind of faking that out you're using a testable and so it's not actually calling be and, therefore, if there was some bug and the calling from A to B, then you would not notice that in your test anymore.
Jeff Terrell: There would be a bug that was hidden in that interface between those two components.
Jeff Terrell: And this is fine integration tests is called an integration is that you're you're integrating these units together and testing the integration of those units.
Jeff Terrell: With a unit test you're not testing the integration, you might test A and B independently and you might have a test that completely covers and completely covers be.
Jeff Terrell: But if you're not doing the integration tests you're not testing the glue between those two components so bugs my hide their underneath your testable.
Jeff Terrell: So that's an important trade off of unit testing might be faster and fastest actually good so that you can have a nice tight feedback loop.
Jeff Terrell: But you got to be a little bit more careful and understand that bugs might be hiding behind test doubles.
Jeff Terrell: end to end tests are challenging because they they consume the actual user interface right there they're using the actual user interface that users would use.
Jeff Terrell: And that means they're probably going to be harder to set up and get going with and probably they're going to be taking more time as well that's some work that the computer has to do to actually fire up the browser and start clicking buttons and things like that.
Jeff Terrell: But they're also valuable for the same reason.
Jeff Terrell: If you want ultimate confidence that your APP works.
Jeff Terrell: Right, an end to end test.
Jeff Terrell: There are no bugs that can hide in an end to end test because you're integrating from top all the way down the bottom.
Jeff Terrell: There are no seams hidden by any test doubles.
Jeff Terrell: So there's a bit of a tension between.
Jeff Terrell: fast and easy to write versus confidence that it gives you and.
Jeff Terrell: You again just have to find something that makes sense for your context.
Jeff Terrell: Another thing to be aware of is, if you have integration tests and especially end to end tests, which are kind of like the ultimate integration test be aware of what I would call the common editorial explosion of different test cases.
Jeff Terrell: Think about all the different cases that each component needs to account for maybe one component has maybe component a has a an F branch in it has an effort and else.
Jeff Terrell: And so you've got two different cases that you guys got kind of consider an A cosby be call see be has three different cases that considers see has four different cases that it considers.
Jeff Terrell: Or maybe these are cases that are sort of implicit in the context, like.
Jeff Terrell: Is there an active session for this user or not, you know these are things that might sort of be outside of the function, depending on how you set it up.
Jeff Terrell: And I formatting messed up a little bit, but this this is supposed to be two times three times for if you're doing integration tests from A to B to C and integrating all three of those components together.
Jeff Terrell: you'll need two times three times four or 12 integration tests to cover all of those cases.
Jeff Terrell: And if you add another case here.
Jeff Terrell: Then all of a sudden you're at.
Jeff Terrell: What.
Jeff Terrell: Point did I even do that right now that's 24.
Jeff Terrell: six times for us 24 yeah I did that wrong.
Jeff Terrell: math okay.
Jeff Terrell: But if see all the sudden had a fifth case and you wanted to cover all the different possible combinations right you'd need, I think 30.
Jeff Terrell: Different test cases to do that.
Jeff Terrell: And this is just a pretty simple example if you imagine like an actual end to end test.
Jeff Terrell: It has to cover not just all the different if statements in your APP, it has to cover like every combination of the possible.
Jeff Terrell: ways that you can go through the F statements, if you really want thorough coverage, I mean nobody does this right, but the point is these end to end tests can there's this common editorial explosion that can happen if you're really trying to be careful so.
Jeff Terrell: Whereas with test doubles if you're doing more of a unit testing approach again bugs can hide behind the test doubles but what this means is that you need two plus three plus four or seven unit tests as opposed to 24 so.
Jeff Terrell: it's big difference right.
Jeff Terrell: You can imagine, be a lot bigger of a difference if you're talking about an end to end test of a reasonably complex APP so the point is tackle variation where it lives.
Jeff Terrell: right if you're variation lives in a your unit test for a should cover that variation your unit test for P should cover the variation of being cover all three of those cases.
Jeff Terrell: Likewise, for see if you do this with unit tests and tests doubles as needed, then, the number of total number of test cases that you need can be much, much smaller and much more manageable.
Jeff Terrell: The other thing to notice is that, in terms of time for testing the test suites going to take a lot longer if you have 24 integration tests, not just because there's 24 as opposed to seven.
Jeff Terrell: But also, because each one of those integration tests it's going to take longer right it's going to involve more code.
Jeff Terrell: Because you're not stepping out you're not faking out the.
Jeff Terrell: dependencies you're actually calling whatever code is there.
Jeff Terrell: there's this idea of a testing pyramid from Martin Fowler who's a pretty well known software engineer he's written a lot of good stuff and talk about software engineering.
Jeff Terrell: He calls it, the testing pyramid the base layer is the unit tests and he's saying, like most of your test suite should actually be this base layer of unit tests.
Jeff Terrell: and on top of that you'll add a few integration tests, probably a much smaller number of integration tests, then you have unit tests, just to make sure that things are connected correctly.
Jeff Terrell: And then, on top of that, at the very top, you might have just one or just a very small number of end to end tests.
Jeff Terrell: This is making sure that everything is integrated correctly, but you don't want to test all the different possibilities and the end to end tests, you want to tackle the variation where it lives do that in unit tests.
Jeff Terrell: So I think that's a good practice to get into as you think about what kinds of tests to right.
Jeff Terrell: Now I haven't given you a lot of practical.
Jeff Terrell: How to about how to write these tests, I hope to get into some of that next time, but hopefully you have a sense of kind of the different ways of testing and how to think about it.
Jeff Terrell: Okay, a couple more topics here.
Jeff Terrell: In general, what you want is tests that give you confidence right you want to be able to be courageous in your software development.
Jeff Terrell: And it's kind of hard to quantify that right if you're trying to say like how confident, am I, or how confident Should I be relative to this test suite it's a bit of a hard thing to quantify.
Jeff Terrell: And so, if you're trying to measure just that, like the health of a test suite it's not easy that easy metric to capture is called test coverage.
Jeff Terrell: And this is certainly not ideal, but it is a useful metric to capture.
Jeff Terrell: Basically, this is saying like what percentage of the code base was exercised by the test suite test suite, by the way, means all of the tests together.
Jeff Terrell: So if you have 100% test coverage, that means that every single line of code in your code base is measured by one test or another or exercised by one test or another.
Jeff Terrell: And, most people are not ever going to try to reach 100% there's usually some code that's boring and really doesn't need to be tested so it's usually not a goal.
Jeff Terrell: again.
Jeff Terrell: evaluate the pros and cons in light of the context, to make a reasonable decision this is kind of what engineering is all about.
Jeff Terrell: And you might recall from the syllabus that in your APP grade.
Jeff Terrell: Which is a great assigned to your team, if you get a great of a one of the qualifications, for that is that you have a good test coverage, which is probably over 70%, although that that can vary depending on the project so keep that in mind.
Jeff Terrell: i've actually had a little bit of pushback from mentors on this point, because they would say it's not appropriate to have a particular test coverage number that you're aiming for, because.
Jeff Terrell: In some Apps 50% might actually be really good and in other cases 80% might not be very good and that is true, but.
Jeff Terrell: I don't know another way to do it, given that every project is different so and I do think it's important that you have good tests, so that this APP that you hand off to your client.
Jeff Terrell: is going to be relatively easy for somebody else to pick up and run with if they need to whether that's another 523 team in the future, or you know the friend of the Nice or Whatever the case may be.
Jeff Terrell: last thing I mentioned about tests is when to write tests.
Jeff Terrell: We saw test driven development was one of the xp practices.
Jeff Terrell: And this was where you write your tests first and then you write your code.
Jeff Terrell: And some people still would would definitely shy away from doing that in fact I I kind of shied away from doing that I did what I decided to call test last Development i'm probably not the only one to call it that, but.
Jeff Terrell: we're basically what I would do is write my code and get my function working and make sure through manual tests that what I was writing was working and working correctly and then I would go and like write the tests that capture that functionality.
Jeff Terrell: And the reason I did that I took me a while to understand why do I want to do things that way and I realized the issue for me was that I wasn't as comfortable in the testing.
Jeff Terrell: Writing tests, as I was writing code, I was a lot more comfortable writing code and so, as I was trying to solve the problem, it was more natural for me to express myself in the implementation, rather than expressing the requirements in test approach.
Jeff Terrell: So that meant I don't know just for that reason I was I would gravitate towards writing the implementation, first in the writing of tests afterwards.
Jeff Terrell: Over time, I got more comfortable with the testing language and at that point, I started to do more tdd.
Jeff Terrell: But it was still I would kind of switch back and forth.
Jeff Terrell: Either way, you do it as long as you make sure that you're going to write your tests they're going to provide confidence to future developers so either way is fine.
Jeff Terrell: And I would say that if you are an experienced developer, you have figured out some sort of a feedback loop to understand whether your code is going to work or not.
Jeff Terrell: And sometimes that feedback loop might be based on tests other times, it might be based on you know refreshing the page or something like that, but.
Jeff Terrell: Setting up some sort of a rapid feedback loop is going to be pretty key to staying focused and being productive in your code so whether you do that with test driven development or test last Development either way it can be fine.
Jeff Terrell: Alright questions about anything so far, if not I might try to briefly show you Cyprus and then we'll do our quiz for.
Jeff Terrell: questions.
Jeff Terrell: Okay, wait, let me see if I can do this real quick show you Cyprus.
Jeff Terrell: This is the Grad tracking APP.
Jeff Terrell: it's Okay, if you can't see this right now.
Jeff Terrell: I have to start a ci Sir oh wait, but actually need to start.
Jeff Terrell: mongodb first.
Jeff Terrell: Okay APP is running.
Jeff Terrell: Okay, I needed to start a database and then a back end process to just kind of run the APP whoops and.
Jeff Terrell: Just this is Cyprus this, these are the integration tests that i've created in this particular APP or actually I didn't create them.
Jeff Terrell: But I can not even sure what a good one to click on would be there, like these different forms that Grad students have to fill out and the Department here's one that's actually relevant to this course programming product requirement if you're a Grad student, you have to have.
Jeff Terrell: done some sort of a programming product which could be like the work that you did in this class some sort of code for somebody else.
Jeff Terrell: And I clicked on that and it's going to run this test and it started firefox up for me I don't know how well, you can see this.
Jeff Terrell: And look at it, using the APP it's actually clicking through the APP right now it's filling stuff in the forums it's checking that different things exist in the page.
Jeff Terrell: clicking the submit button, a new page loaded it tested to make sure, everything was the way it should be, and that test is done so that took 16 seconds, it was clicking through the APP, and this is an example of a Cypress test.
Jeff Terrell: This is an end to end test for a web APP.
Jeff Terrell: And the code is fairly straightforward, it has an API for interacting with the webpage you know find this button click this thing fill this out.
Jeff Terrell: That kind of stuff.
Jeff Terrell: Questions about this.
Okay.
Jeff Terrell: Okay well let's let's do this for them.
Jeff Terrell: me see here.
Jeff Terrell: i'm gonna stop recording.