FactoryGirl and Faker

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'll take a look at factories.

What if our objects become very complicated to create,

and we want to keep that complexity out of our test cases.

And we'll take a look at FactoryGirl as one implementation of a factory.

And at some point, we need test data.

What do we use to fill in the fields of our objects?

And we'll take a look at a fun gem called Faker to play that role.

We see instances of foo created all over.

It's a very simple object, it's hard to get wrong.

But what if it were a bit more complex and our test created it differently,

let's say if they created it without a name.

And at some point later in the creation block, they set the name,

and saved the result.

Should end up with the exact same object, correct?

So if we run our test, everything's working with the new block approach.

But what if foo were more complex?

What if the name column became required?

And we put a null constraint on that column that made it illegal in order for

any foo to be created without a name.

We'll put this construct not in the change block, but

in an explicit up-down because change column is not a reversible construct,

you actually have to tell it what to do, going in either direction of migrate.

So if we migrate that and we run our test, it fails,

because of a constraint violation going on.

Okay?

Now, the author of the test said, what's wrong?

This test passed, yesterday.

Everything was fine.

Well the trouble is, the details of the object changed.

Now, they really didn't care.

Authors of tests many times don't care specifically about the foo object.

This particular test does, but most of the time, they just want an example object.

Give me a valid object to stand in its place.

So how can we extract this from our code?

How can we fix this?

Where would be a better place to put this?

And the answer would be a factory.

And in our case we're going to use FactoryGirl.

And let's start by updating our gem file.

And while we're at it we're going to bring in another

gem called faker which we'll use later on in the lecture.

So we'll run bundle,

then when we finish that we'll run migrate against the development database.

The last time we ran migrate it was against the test database.

So with FactoryGirl installed, we can go ahead and create our first factory.

Which I'm just going to call foobars.

It's going to be a file that's going to be a collection of factories that I'll use in

this lecture.

So if you see at this point, our spec has been expanded to not only have models,

requests, and support, but has also added a factories directory.

This will be the location we use in order to instantiate all of our FactoryGirl

factories.

So it created our first factory.

It named it after the file that I asked it to create.

I'm just going to change this one to be foo_fixed.

You'll see in a second why I picked that name and

I have to tell it what class it is.

It's creating an instance of a foo.

The name, property that I give it, is going to be test,

because we want to just put it back, the capability it used to have.

The capability to create a Foo with a name test.

And if I come into my rails console, and if I were to just say,

let's say Foo, let me do a couple of things here.

I go Foo.new you'll notice that the name is nil.

And if I do a Foo.create I should get a failure

because there is a constraint violation.

But if I say FactoryGirl.create(:foo_fixed),

I get a successful create of my object

because it is supplying a name when it creates things.

Okay, now if you get tired of typing the word FactoryGirl each time,

you can eliminate the need for that syntax by including

FactoryGirl::Syntax::Methods and

then what you have is now optional.

I'll go ahead and keep the prefix just so I'm more explicit.

All right, before we look at the details of FactoryGirl,

I want to put ourselves in a particular state.

I want to create a default factory based off of currently, foo_fixed,

which is our default implementation, where we were creating it, with fix.

Now let me go back to our spec and

change this to use whatever the default factory is.

I don't care what it is.

Well, it does care.

And I'm sure you can see lots of problems with this, coming up.

But at this point in time, it's fixed.

When I go to create a foo, it creates me something that works in my case.

All right, so in this state, I want to now look at the details

of how we can do other factories and then come back and fix this class for real.

Because as we change those factories, tests like this where we're looking for

particular values are going to give us a problem.

So in summary, during this lecture we talked about the problem of having

some complex objects and maintaining those for our tests.

And we identified a way to fix it, namely FactoryGirl.

Now, we went through the installation details of FactoryGirl and Faker,

and basically got a start in our overall solution.

So what are we going to do next?

Let's go through the details of some of the factories and

Faker data that'll help make up our solution.

Basically, let's continue what we were talking about in our next lecture.

See you then.

探索我们的目录

免费加入并获得个性化推荐、更新和优惠。

Coursera 致力于普及全世界最好的教育，它与全球一流大学和机构合作提供在线课程。

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

通过 App Store 下载

通过 Google Play 获取