DatabaseCleaner Optimizations

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.

Module 3 Introduction4:19

Spec Anatomy Part 1: Database Interaction and Blocks6:25

Spec Anatomy Part 2: Thinning Examples5:32

Spec Anatomy Part 3: Pending Examples and Lazy/Eager Let Blocks6:08

RSpec with Mongoid9:55

DatabaseCleaner with ActiveRecord6:40

DatabaseCleaner and SharedContexts5:46

DatabaseCleaner with Mongoid5:32

DatabaseCleaner Optimizations5:59

FactoryGirl and Faker6:07

FactoryGirl Factories10:21

FactoryGirl and Faker Data9:01

Rencontrer les enseignants

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

[MUSIC]

In this lecture, we're going to discuss some database clean up optimizations

because we don't want to force many of our tests to use a one size fits all

that can cause them to go through many repetitive and expensive population and

clean up steps.

All right now, the last thing I'd like you to consider is more customized strategies.

If we notice, every one of our examples, creates something in the database and

does read only.

Creates something in the database and read only.

And not only that, it's the same thing every single time.

So for the purposes of this lecture,

what I'd like you to do is not think of this as just one insert.

Think of it as hundreds of inserts and

may take 5 to 20 seconds in order to get put in place.

All, what would we do then?

Well one of the things that we prefer to do is that at the beginning of the overall

example group, we go back to this strategy where we create a block,

create our object and then allow others to access it off of @foo, all right.

Well, let's say we like this simplistic syntax, and

we didn't want to change things.

So what we could do, so we could come up here and

just define the let for column foo.

So I have a before block that's going to get executed before any test runs.

That before block is going to take 5 seconds, 10 seconds, in imaginary seconds.

And then whenever any one of my tests need to access their foo,

it's going to go dig in to that populated database.

Okay, grab this one, grab that one.

Okay?

And so what I don't want to do is clear the database at all.

And so now I can just go through each of these subjects a little different.

We can go any which way here.

I'll just go ahead and return.

Either @foo or [INAUDIBLE].

And we come down here and it's the same.

Notice that none of my examples are changing the database.

They're just on queries.

They're just inspecting things.

And that's my before block that sets everything up once and

let's everybody query off of it.

So if I rerun my test, one of the things I'll notice is that that

last test was, it's not, it's really not appropriate for

what I'm trying to do right now, so let me get rid of it.

It was trying to show something about the eager and

the lazy, and we've changed our model significantly since then.

All right so foo, no leakage, of course.

And then if I look at the output,

you notice actually it even looks much more efficient.

It goes in, it clears it, it inserts a record once.

And then, all of my tests after that just go in there and select.

And at the end we clear it out.

Pretty neat stuff?

As I said, think of this block up here as a chunk of time

that you want to manage how often it happens.

And then what we got rid of was the deletion

of that data between every one of the tests.

So if I brought my scope back, that's going to clear things out in between tests

and I were to default this to truncation and rerun my tests, it's going to fail.

And the reason it's going to fail is my data

was inserted once at the very beginning.

And the cleanup that occurred, per example,

by putting that scope back in, removed them, removed them, removed them.

This also brings up another point.

Now notice the start and the clean that occurs is not a replacement for

transactions.

When using the truncation strategy, it's going to remove, not only what you put in

since the start, it's going to remove whatever's in the tables.

All together, so keep that in mind.

Now if you remember back, we have more than just a test that we have

been recently working with, we have the request back from module one.

And if we include the shared context, we can just remove these and

play the game that says, they don't know everything that needs to be cleaned up.

So now if we run the request specs.

Everything's working the way they should.

And the test have to know a little bit less.

Now I'm already getting tired of doing two include lines when that might be

a significant number of my tests.

So why don't we create an each

And put that one in play as well, okay?

In summary, database population can be time consuming.

What we have right now is trivial.

But think tens of seconds, maybe minutes.

Database cleanup can be simple.

Just run a command, it's gone.

Well, we don't want to be spending all day waiting for a test to go to

the next example, go through many seconds of setup and then nuke it.

And go to the next test that could have used the exact same data that was

there before.

We can restructure our tests.

Restructure our clean-up strategies, and that's what we took a look at.

What's next?

Well lets take a look at FactoryGirl, and

how it can help us create prototype objects for our tests.

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