DatabaseCleaner with Mongoid

Loading...

Do curso por Johns Hopkins University

Capstone: Photo Tourist Web Application

18 classificações

Johns Hopkins University

Capstone: Photo Tourist Web Application

18 classificações

Curso 6 de 6 em Specialization Desenvolvimento Web com Ruby on Rails

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

Na lição

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

Conheça os instrutores

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

[MUSIC]

In this lecture, we'll discuss a cleanup strategy for a MongoDB collections and

how we can integrate the Mongoid cleanup with ActiveRecord.

So let's turn our attention back to Mongo.

We look at a bar spec, we'll see that one of the first things that we were doing

was just saying we need to remove everything.

And so let's apply database cleaner to this.

Well, one of the first things we need to do is establish our strategy,

which is not going to be transaction.

It is going to be truncation, because Mongo does not support transaction.

And then the logical equivalent to Bar.delete_all is to do clean with

truncation.

What we're saying is that there may be more things than bar that need to be

removed but we don't want to worry about it, okay?

Then if we were to just do a logical equivalent of what we had in place, and

what we could do is add a before block with a DatabaseCleaner.start.

And replace the processing in the after with a clean, okay?

And then let's go ahead and turn on debug, And run our test.

If we take a look at the results, you'll notice that ActiveRecord was consulted,

but because we didn't have it listed as a strategy,

there's nothing being truncated within the scope of this test.

But the logical equivalent of looking at the migration table is

looking at this collection within Mongo.

You're saying, well, what kinds of things can I drop that aren't the system?

And so it knows to delete bars, we're doing some inserts.

It knows to delete bars, doing some inserts.

And taking care of cleanups.

And at the end, we don't have any leakage.

Okay, we've just reimplemented what our manual strategy was

in terms of DatabaseCleaner.

As we did with ActiveRecord, we would like to dry this a bit and

be able to integrate this with our other DatabaseCleaner.

So let's take our Mongoid strategy over to the database_cleaner piece and

declare a strategy for mongoid for truncation,

right next to the active_record strategy.

Because even though we have a very simplistic data model to date,

when things are separate, we will soon get much more complicated down the road and

we will just need to say, whatever I need to get rid of, get rid of.

We can come back and replace, This here.

Then we have a choice.

Do we want to replace exactly what we had?

Okay, let's go ahead and do that.

Let's grab the name of the scope so we don't make a typo.

Include the context and we should be good to go.

If we rerun our tests, everything should work.

So if we take a look at the results,

what we'll notice is a little bit of difference.

If we go scrolling up to the beginning, so

now not only was the ActiveRecord::SchemaMigration consulted,

some work was actually done to it.

So you notice that he went to postgress and

said, what kinds of things do I need to clean up?

Because we included active record strategy within what we just did.

So since the active record side of the house has a database table called foos,

it is truncated prior to running our tests on the mongo side.

Then when we actually do our insert, the Mongo side is cleared out.

And foos is truncated as well with each test.

And you see that pattern repeating.

So what we've been able to do is get ready for

the future, where we're going to have a moderately complex database structure.

And what we would like our test to do is just say, handle it.

Now here what I was able to do is say,

globally, I know I want to get my strategy set up.

But here's the only context that's actually changing the database.

I can save myself some time by doing it here.

And when I say time, fractions of seconds or seconds.

Okay, and then I also realize that by doing that, we have also impacted foo.

Foo, when it does its cleanup, it will also be bringing in the Mongo side.

And so if we look back to the set up of foo, it looked into the migration,

it consulted what tables to drop and I don't have the Mongo debug turned on here.

But know that it, too, would've been going over to Mongo and saying,

we're going to clean out anything that's not a system type collection.

Pretty useful.

In summary, our database is more than just ActiveRecord.

We're going to need a strategy for Mongoid, as well.

And not only that, we're going to need a combined strategy for ActiveRecord and

Mongoid, as our solution spans both databases.

What's Next?

Well, let's take a look at some Optimizations.

We don't want to sit around and

wait for our test to run with some one size fits all database cleanup strategy.

Explore nosso catálogo

Registre-se gratuitamente e obtenha recomendações, atualizações e ofertas personalizadas.

O Coursera proporciona acesso universal à melhor educação do mundo fazendo parcerias com as melhores universidades e organizações para oferecer cursos on-line.

© 2019 Coursera Inc. Todos os direitos reservados.

Baixar na App Store

Baixar no Google Play