Spec Anatomy Part 2: Thinning Examples

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]

As we look further into the anatomy of RSpec, in this lecture,

we're going to look to thin down our example blocks.

Breaking down our compound tests into isolated tests

to better express the requirements and our ability to meet those requirements.

We'll cover one-liner examples,

where the power of the matcher really starts to shine.

And then we'll take a look at the subject object,

if we want to reduce the verbosity of our examples a bit further.

Okay, but let's say I had an error early on in my block.

And let me purposely cause an error.

Now, if I run my test, it's going to report the error

that I purposely caused in there, but it's not going to tell us anything else.

All our other expects do not execute.

So what I can do to fix this is I can go ahead and

separate these into separate blocks, separate examples.

And say the first one is, well, it's going to be persisted.

And the next one, it's going to have a name.

And the last one is it's going to be found.

And let's see if we can improve some of the English.

Okay, if we rerun our tests, it'll be a little noisy, but

it'll be able to figure this out.

We start out with a failure.

It got inserted, but because we inserted an error, it failed.

But that didn't cause it to stop.

And then in the next test, the transaction began, it inserted the record, and

it ran the tests.

And in the third one, it started the transaction and it ran the test,

and each time it was able to roll back.

And so we're able to get more information.

Three examples and only one failure, we've got some isolation going on.

So in concert with our separation, let me fix this, these typos.

We've separated things into blocks.

And we can go a step further.

We can just get rid of all the text.

Now here's where the power of the matcher comes in.

The matter is going to be used to express the status of the test, or the spec.

And it probably would help if I turned off debug.

And now if I run my test, what you'll notice is that we have our created Foo,

and it says it should not be persisted.

It should equal test, it should not be nil.

So where did that text come from?

It came from the matcher.

Well, this one is a customized matcher that comes from, I guess,

I would assume Active Model.

And you see how this is decent English.

You know, it's talking about, it should be persisted.

This matcher is just string equality.

It really isn't telling us any business information,

it's not saying like it has to have a name, or a name of a particular value.

And this is just a value of evaluation, be nil, it's not saying it can't be found.

So when I was saying earlier about custom matchers,

if we want to cut down on the amount of documentation that we type into our tests,

we can build this custom marchers, which I won't go into.

But we can build custom matchers that are for

a particular business purpose that will kick out the right information.

Okay?

Let's at least do this thing, passing in all colors.

So persisted equal to test and not nil.

Then we can notice that we have a bit of a shorthand going on here.

And let's go ahead and duplicate this.

And since everybody's referencing the same foo,

what we can do as a shorthand is just go ahead and

refer to what's being created as the subject that's under test.

So instead of expect foo to be persisted, we'll just say,

whatever the subject is is expected to be persisted.

And then if we actually have to refer to the subject, we can just call it subject.

Okay, this isn't any fantastic capability, but anything that allows us to

shorten up or make our tests more succinct in expression, there's some value in that.

But you'll notice that they're identical.

So in summary, in this lecture, we looked to make examples a bit more concise.

We broke down our compound example into individual, and

then we even went one step further and even took them down to one-liners.

Now, because our matchers were not targeted at our business domain,

they gave pretty generic responses.

So it would be questionable whether the one-liners were actually appropriate in

our case.

Or we can go back to an example block,

where we had the ability to express the details of the requirement in a string.

We took a look at subjects, where if we're trying to focus on a particular object,

we can make that object our focus,

be a bit more terse in the expressions within our examples.

So what's next?

Well, let's wrap up this anatomy discussion with pending examples and

lazy/eager let blocks.

探索我们的目录

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

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

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

通过 App Store 下载

通过 Google Play 获取