Spec Anatomy Part 1: Database Interaction and Blocks

Loading...

來自 Johns Hopkins University 的課程

毕业项目：旅游照片 Web 应用

18 個評分

Johns Hopkins University

毕业项目：旅游照片 Web 应用

18 個評分

課程 6（共 6 門，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

從本節課中

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

與講師見面

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

[MUSIC]

In this lecture, we will start our look at the anatomy of Rspec by first turning on

debug so we can look at database interactions.

We will also look to refactor our example blocks so that we can extract Common Logic

into what could be before and after blocks as well as let blocks.

I want to start out by adjusting the spec that we have in place.

Nothing wrong with it, it's just my example is a little different.

So I'm going to create an example, and I'm going to create a Foo in this example, and

I'm going to expect it be persisted, that it have a particular name and

that we're able to find it.

And I'm going to express all those facts in the metadata for the example.

Created Foo will be persisted with have a name and found.

A little bit of a long winded thing.

Now, what I'm also going to do is go into the Rails console in the test environment,

and poke around.

And see that I don't currently have any foos.

And if I were to run this test, I see that I'm successful.

However, the things were very much in the background.

So one of the things that you may want to do is actually see

the interaction with the database.

Now I mentioned that one of the places we can configure the spec

is in the spec helper.

And what we could do is configure rails.

But if you remember what I said, the spec helper was generic.

It knows nothing of Rails.

Which means we could move this over to the Rails helper, okay.

That's a possibility.

And we also have a chance to put it in the config as well.

Now when we run our test, we get not only the status of the test, we get

the actual database interactions that are going on behind the scenes in the test.

And this is mostly what we're focusing on.

At the model level.

So the next thing you notice is our example is a little busy.

So let's go fix that by adding an example group using

context And place our example inside.

So no longer do we need created foo,

because the example group has taken care of the that portion of the requirement,

however, we're still creating foo inside of here.

Well we can fix that by taking the create and putting it in a before block.

We can either do before each or we can do it before the entire thing starts.

I don't know where that semicolon came from.

All right, so before all I'll create my tests and now [SOUND] I'm running.

So now if I rerun the tests,

you notice that my block can't access what was done in the before block.

All right? Well that makes sense.

You can't see that.

So I can declare it as an attribute, that's one way to fix it.

Okay now if I rerun the test, everything looks good or it appears to look good.

If we do a count we'll notice that we've got an extra object

that may have had some junk in there.

And that every time we rerun the test, we get another one.

Well, that's because the before block

is running before the transaction started that's running the test.

Okay, one way we can fix this is we can create an after block,

And basically just undo what we did.

So we say foo, we want you gone.

So now if we rerun the test, you notice the delete happens after the roll back and

everything's done and if we check our count we're down to zero.

Okay, well that's a way to solve it.

We can also solve it by running the before with each run.

Okay, if we rerun now, now the insert is happening as a part of the transaction.

And is obviously part of the rollback.

And if I do a count, we have no object, okay.

No side effects now we're gotten rid of things,

but we have polluted the global space with this at sign foo.

We'd like to get rid of that, okay, let's do that.

Let's not use an at sign foo, but let's use this construct called let,

which will define a function that will only be called once and

when it's called, it'll return whatever is returned from this block.

All right?

So now if we rerun our test, it'll act very similar to before.

And that the insert is happening within the transaction and

as part of the rollback.

And now our count is also at zero and

with this approach we have not polluted the global naming space of the test and

we have rolled back our database to our starting point.

Okay that's not half bad, so

in summary we started our discussion of the anatomy of R spec by showing you

how to enable and disable console debug of database interactions.

Note that while this is disabled, it is being written to the test log, so

you can find it even though it's not coming to the console.

We looked at DRYing examples, leveraging before and after blocks, and

leveraging attributes for sharing access between the blocks.

We looked at the impact of applying :all and :each to our before and after blocks.

Whereas :all causes it to run only before and after all of the examples are run.

Whereas :each will run within each example,

making it part of the transaction of that example.

We also looked at the power of the let block.

Basically replacing the need to do a before each kind of block.

And offer it a lazy instantiation way to do that.

So what's next?

Well, we'll take a look at Thinning Examples.

探索我們的目錄

免費加入並獲得個性化推薦、更新和優惠。

Coursera 致力於普及全世界最好的教育，它與全球一流大學和機構合作提供在線課程。

© 2018 Coursera Inc. 保留所有權利。

通過 App Store 下載

通過 Google Play 獲取