0:18
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.
0:47
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.
1:41
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.
2:10
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.
4:24
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.
Dr. Douglas C. SchmidtProfessor of Computer Science and Associate Chair of the Computer Science and Engineering Program
Michael WalkerInstructor - Graduate Student pursuing PhD in Computer Science
Dr. C. Jules WhiteAssistant Professor of Computer Science
