Code Coverage

Loading...

En provenance du cours de Johns Hopkins University

Capstone: Photo Tourist Web Application

18 notes

Johns Hopkins University

Capstone: Photo Tourist Web Application

18 notes

Cours 6 sur 6 dans Specialization Ruby on Rails Web Development

In this Capstone project for the Photo Tourist you will implement a Ruby on Rails web application that makes use of both a relational and NoSQL database for the backend and expose the data through services to the Internet using Web services and a responsive user interface operating in a browser from a desktop and mobile device. You will have a chance to revisit and apply what you have learned in our previous courses to build and deploy a fully functional web application to the cloud accessible to your co-workers, future employers, friends, and family. In developing the Photo Tourist web application, you will get to work with different data types and data access scenarios (e.g., fielded data display and update, image upload/download, text search, access controlled information) to provide your users the ability to show off their photos and information from trips they have taken and to seek out photos and information from trips taken by others. Using the application you develop, your users will be able to • Create an account • Upload and download photos to the site and make them accessible to others • Provide descriptions of trips and photos that others can read • Organize photos by location and trip, • Find photos based on location • Find photos based on text searches of descriptions • Locate the place where the photo was taken on a map

À partir de la leçon

Testing

In this module, you will learn how to development model, request, and feature specs using RSpec and to leverage gems like DatabaseCleaner, FactoryGirl, and Faker in building those specs. You will also learn how to DRY their tests using RSpec shared_contexts and shared_examples as well as Ruby modules for helper methods. All use of tests within the capstone will be "integration-style" tests, going to the database and back. We will not have time to implement pure unit tests for individual components. For model testing, we will focus tests on factories, query scopes, relationships, and facade methods interacting directly with PostgreSQL and MongoDB databases. We will address the general purpose and custom techniques for managing the database state during cleanup. For API testing, we will form a hefty set of RSpec shared_contexts and Ruby helper methods for the request specs that will take care of the details of many CRUD behaviors and other tedious, repetitive tasks. The API is not only easier to test than the Web UI, it is a first-class external interface deserving of separate testing. During test coverage, you will learn internal Rails error handling techniques that will provide the web client a proper and sane web reply in the face of errors. For Web UI testing, we will introduce Capybara for building feature tests and the role of the RackTest, Selenium, and Poltergeist/PhantomJS drivers for implementing UI testing with Javascript. Although Capybara provides a nice interface for expressing Web UI tests, the asynchronous nature of Web UIs make them extremely difficult to test without well thought out decisions during development. This course has a special emphasis on teaching you how to develop automated integration tests at all levels of the architecture, including the Web UIs. It is recommended that you review this module and sample further test-related lectures in follow-on modules to get a good understanding of how testing can best be leveraged in a full stack development (within constraints of the course). Except for the seasoned RSpec and Capybara user, there is no shortcut through this module.

Capybara Setup6:46

Selenium Webdriver8:42

Debugging Capybara/Selenium Tests2:59

Poltergeist/PhantomJS Headless Webdriver6:56

Capybara Testing with Docker (Optional Lecture)14:59

Capybara Usage10:58

Capybara Waits6:22

Foo Feature Spec: Foo List10:39

Foo Feature Spec: Create Foo8:34

Foo UI Helper Module8:10

Code Coverage3:26

Rencontrer les enseignants

Jim Stafford
Adjunct Professor, Graduate Computer Science
Computer Science, Whiting School of Engineering

[MUSIC]

In this lecture, we will discuss Code Coverage.

How much have we been testing or not testing in our application?

To get started with test coverage, we need to visit our Gemfile and

add this simple coverage Gem And run bundle.

You also need to edit our spec_helper.

And add a configuration that, if we supply the environment variable coverage,

then it'll bring in simple coverage, Gem.

And we'll define specific reports like a report centered around foos,

a report centered around bars.

And to ignore reporting on coverage on things in the spec folder, or

anything in the config folder.

So we run our test by adding coverage equal true prior to the execution.

And it tells us that it has written some files into the coverage directory.

If we navigate to our application, go into the coverage, index HTML, we see a front

page of a report giving us an indication of the percentage of the class that's been

tested, the number of lines in it, relevant lines and things like that.

And then a break down of here's your testing around foos,

here's your testing around bars and here are the classes that aren't in any groups.

And you know, we've seem to have done a pretty nice job at testing what's there.

If we were to go into an individual class, it's telling us what we have and

have not tested.

And here's a piece of useful information.

We have not tested a create failure.

And we have not tested an update failure.

And just in staring at this, I see a problem.

Notice how we're reporting the error in these cases?

It's just a straight what are our errors.

Well if you remember our application controller,

it actually did some formatting.

So this report is pointing out initially that even though we have

almost 92% of our classes coverage, we failed to test an error case.

Interesting stuff.

All right, I'll leave it to you to dig in and see what else we can find.

But one of the last things we probably want to do is add that directory to our

gitignore because we don't need to clutter our repository up with stuff like that.

And then, actually, that is a good candidate report for

the build server to kick out.

Let's see if we can find the time to do that.

Okay, so in summary,

hopefully we all can agree that testing our application is a very important thing.

And that a Code Coverage report can do two things, it can provide confidence that we

have tested our application, or it can identify gaps in our testing.

Which we actually saw as a part of our foo testing.

What's next, security.

Actually that's not next.

There's an assignment before we get to security, but

when we get there we'll be talking about authentication,

authorization from the back end server to the front end web displays.

It's going to rock.

Explorer notre catalogue

Rejoignez-nous gratuitement et obtenez des recommendations, des mises à jour et des offres personnalisées.

Coursera propose un accès universel à la meilleure formation au monde, en partenariat avec des universités et des organisations du plus haut niveau, pour proposer des cours en ligne.

© 2018 Coursera Inc. Tous droits réservés.

Télécharger dans l'App Store

Disponible sur Google Play