[MUSIC] I want to talk about some different styles of testing so that we can hone in on the rationale for some of the things that we're going to be looking at in a little bit. Now, there's a couple ways you can test an application. Let's say that we built our GUI application and we have something simple, initially. Let's say, that we go and we add one drop down menu that we're going to use. And then we're going to have a go button, let's say for example, and then depending on what you select here, you end up in a different screen of the application, seeing a list of items. And so, this is the feature that we're trying to implement, let's say, in our application. Now, a lot of us test in a very ad hoc way. And it's very rare that a software programmer does absolutely no testing whatsoever. Almost everyone naturally tests to some degree or we hope they naturally test to some degree by at least running their code and seeing what happens. So, the ad hoc way of testing is, I'm going to go and I'm going to run this code, I'm going to make a selection in this text box, I'm going to click my button. I'm going to see that this list displays, maybe I'll scroll up and down the list a little bit, and I'll see, is the contents of the list what I expect it to be? So, we always have some notion of something that we're expecting. We have a series of expectations. We have a series of initial state that we're working with, so we expect that we're in some initial state. If we take a sequence of actions, that we're going to end up in some other state that we care about. And almost every programmer always, at least to some degree, does this manually. We have other ways of doing it, that can be better. But most often people at least do some type of really manual ad hoc testing that looks like this. Now, why would we maybe want to do this differently? Well, let's think about this. So, let's assume that I decide to go, and add something simple. Let's say I decide to go and change the styling of these list items. Maybe I'm going to add some additional icons, or something on one side of these list items. And so I go in and I make this change. Now, in order to test this, well, first if I'm doing testing, let's say for an Android application, I have to launch my Android application, I have to wait for it to load, I then have to navigate to this particular screen. So, let's say that I had three other screens that came before this. I have to go and manually click through each of those screens in order to finally get to this particular screen. And if there's any type of state that I have to set up from these other screens that get transferred here, if I'm doing this manually I have to make sure I click the right buttons here, enter the right values here, let's say, enter the right values here, select the right options. Then I get to this screen and then I say, okay, you know what? These icons are only going to show up when I select the two option. So, I go and I select the drop down menu, I put it to two, I click this button, I get the list, and then I see my list and I notice that you know what? The margin here's not quite right. All these icons are offset a little bit more than I want them to be. And, well, actually no, some of them are correct. And so suddenly I have this state where something's happening. I don't know exactly why. I've got this complicated flow of actions that I have to take to try to reproduce the issue and see if it's correct. And so, now as the programmer, let's say I want to go and try to do something to effect this margin. Well, I go and I make, let's say, a one line change. I go and change the margin just a little bit. Or maybe I find some particular case statement or some if statement that's helping decide these margins. And I go and I make a subtle tweak to it. Well, in order to test that tweak, I gotta go back to square one. I gotta go back to launching my application, filling in the correct values on this screen, filling the correct values here, selecting the right options, getting here, selecting two, hitting the button and opening the screen again. And what would be a very simple change and something I be able to normally enact really quickly, because I have to test the effect of it and see if it's working or not, I have all of this overhead I've created. So I've got this tiny little change that I'm making and I've got this huge testing overhead that I'm having to deal with every time I make that change. And so, whenever we have this case where a small change creates a huge amount of testing overhead, we have a lot of things that typically happen. One of the things that typically happens is, as a programmer I'm often quite lazy, unfortunately. And so, when I start having a lot of overhead for testing, what I tend to do is start to test less and I become more reticent, I'm more scared to make changes. Because I know that if I make a change, I'm now going to have to go through and run all of these little screens, see what happens, get the output of the list, and it's going to be a pain. As a programmer that's not what I want. What I want to do is i'm excited about the creation of the software. I'm excited about the programming itself. I'm excited about doing this part, and I really don't like doing this part typically. Some people really like it, this is the thing I don't like doing. So, I try to avoid effort up here. I want to do this, I want to know that it's right. But I'm having fun down here. So, I'm trying to focus as much of my effort down here in the actual creation of the software. And make it fun to do this. Manually going through and running through a sequence of things is not what I think is fun.
