Styles of Testing

Loading...

Del curso dictado por Vanderbilt University

Engineering Maintainable Android Apps

121 calificaciones

Vanderbilt University

Engineering Maintainable Android Apps

121 calificaciones

Curso 4 de 5 en SpecializationAndroid App Development

Engineering Maintainable Android Apps, which is a 4 week MOOC that shows by example various methods for engineering maintainable Android apps, including test-driven development methods and how to develop/run unit tests using JUnit and Robotium (or equivalent automated testing frameworks for Android), as well as how to successfully apply common Java/Android software patterns to improve the extensibility and clarity of Android apps. Students will work on the appropriate automated unit quizzes, based on the material covered in the lecture videos. These lessons will demonstrate the benefits of good software engineering practices that are targeted at creating maintainable code for mobile apps. There will be roughly 3-4 hours of student engagement time per week, including video lectures, and quizzes. The ordering of the modules within the course is designed to be flexible. In particular, students can watch the videos in whatever order suits their experience and needs, e.g., they may want to watch the unit testing videos prior to the software pattern videos if they prefer to learn about unit testing first.

De la lección

Software Engineering & Testing I

Software Engineering as Search7:11

Unit Testing8:01

Unit Testing with Android Studio21:52

The Importance of Test Automation8:47

Code Coverage9:05

Styles of Testing6:34

Conoce a los instructores

Dr. Douglas C. Schmidt
Professor of Computer Science and Associate Chair of the Computer Science and Engineering Program
Electrical Engineering and Computer Science
Michael Walker
Instructor - Graduate Student pursuing PhD in Computer Science
EECS
Dr. Jules White
Associate Professor of Computer Science
Electrical Engineering and Computer Science

[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.

Explora nuestro catálogo

Inscríbete de manera gratuita y obtén recomendaciones personalizadas, actualizaciones y ofertas.

Coursera brinda acceso universal a la mejor educación del mundo, al asociarse con las mejores universidades y organizaciones, para ofrecer cursos en línea.

© 2019 Coursera Inc. Todos los derechos reservados.

Descargar en la App Store

Consíguelo en Google Play