In this tutorial we will show you how to add items in shopping cart using drag and drop feature by using jQuery,Ajax and PHP.Drag And Drop is the modern and easy way to add items in shopping cart you only have to drag an item and drop it into the cart and the items will automatically added in your cart.
The post Drag And Drop Shopping Cart Using jQuery,Ajax And PHP appeared first on jQuery Rain.
This jQuery plugin helps users to select products for comparison. Where user needs to click on products to add them for comparison. It also contains preview panel of selected products for comparison.
The post Products side by side Comparison using jQuery appeared first on jQuery Rain.
Lightgallery.js is a full featured JavaScript lightbox gallery. No dependencies.
The post Lightgallery.js : JavaScript Lightbox Gallery appeared first on jQuery Rain.
Are you new to Rails? New to coding? Curious about RSpec and how you can start testing? If so, this article should be a good starting point for you to get into test-driven development. It will explain to you the why and the how, and it will give you a survival kit to go on your first testing spree.
What is RSpec good for? RSpec is very useful on the Unit Test level, testing the finer details and the business logic of your app. That means testing the internals like models and controllers of your app. Tests that cover your views or feature tests which simulate more complete user flows, like purchasing an item, will not be the focus that RSpec is made for. RSpec does not make use of a web driver—as Capybara does, for example—that simulates a user's interactions with an actual site or a representation of it.
Test-driven development (TDD), what’s the point? Well, that is not that easy to answer without feeding you some clichés. I hope this doesn’t sound evasive. I could provide a quick answer, but I want to avoid sending you home hungry after having only a small snack. The result of this little series about RSpec and testing should not only give you all the info to answer this question yourself but also provide you with the means and the understanding to get started with testing while feeling a bit confident already about the testing thing.
Beginners seem to have a harder time getting into RSpec and the TDD workflow than starting to get dangerous with Ruby or Rails. Why is that? I can only guess at this point, but on the one hand, the literature seems mostly focused on people who already have some programming skills under their belt, and on the other hand, learning all the stuff that is involved to have a clear understanding is a bit daunting. The learning curve can be quite steep, I suppose. For effective testing, there are a lot of moving parts involved. It’s a lot to ask for newbies who have just started to understand a framework like Rails to look at the process of building an app from the opposite perspective and learn a completely new API to write code for your code.
I thought about how to approach this “dilemma” for the next generation of coders who are just looking for a smoother start into this whole thing. This is what I came up with. I will break the most essential syntax down for you without assuming much more than basic knowledge of Ruby and a little bit of Rails. Instead of covering every angle possible and confusing you to death, we will go over your basic survival kit and try to paint the bigger picture. We will discuss the “How?” rather verbosely in order not to lose new coders along the way. The second part of the equation will be explaining the “Why?”
If I’m lucky, you’ll get away with a good basis for more advanced books while feeling confident about the bigger picture. Ok now, let’s walk the walk!
Let’s get back to the purpose of testing. Is testing useful for writing better quality apps? Well, this can be hotly debated, but at the moment I’d answer this question with a yes—I’m in the hipster TDD camp, I guess. Let’s see why tests provide your apps with a couple of benefits that are hard to ignore:
They check if your work functions as intended. Constantly validating that you are writing code that works is essential to the health of your application and your team’s sanity.
They test stuff you don’t want to test by hand, tedious checks that you could do by hand—especially when you’d need to check this all the time. You want to be as sure as possible that your new function or your new class or whatever does not cause any side effects in maybe completely unforeseen areas of your app. Automating that sort of thing not only saves you a ton of time but will also make testing scenarios consistent and reproducible. That alone makes them much more dependable than error-prone testing by hand.
We want to make sure the app behaves in a certain way, in an expected way. Tests can make sure to a pretty high degree that the way users interact with your app is functioning and avoiding bug scenarios that you were able to foresee. Tests check that your application works the way you designed it—and that it continues to work after you introduce modifications. This is especially important when your test suite informs you about failing scenarios about implementations of your app that might be old and therefore not exactly at the back of your brain anymore and not considered while you introduced some new functionality. In short, it helps to keep your app healthy and avoids introducing tons of bugs.
Automating tests make you actually test more frequently. Imagine if you have to test something for the 40th time for some reason. If it is only a bit time consuming, how easy will it be to get bored and skip the process altogether? These sort of things are the first step on a slippery slope where you can kiss a decent percentage of code coverage goodbye.
Tests work as documentation. Huh? The specs you write give other people on your teams a quick entry point to learn a new code base and understand what it is supposed to do. Writing your code in RSpec, for example, is very expressive and forms highly readable blocks of code that tell a story if done right. Because it can be written very descriptively while also being a very concise Domain Specific Language (DSL), RSpec hits two birds with one stone: not being verbose in its API and providing you with all the means to write highly understandable test scenarios. That’s what I always liked about it and why I never got really warm with Cucumber, which was solving the same issue in an overly client-friendly way, I think.
They can minimize the amount of code you write. Instead of spiking around like crazy, trying out stuff more freestyle, the practice of test-driving your code lets you write only the code that is necessary to pass your tests. No excess code. A thing you will often hear in your future career is that the best code is code you don’t have to write or something. Why? Well, most often, more elegant solutions involve lesser amounts of code and also, code that you don’t write—which might be unnecessary—won’t cause any future bugs and doesn’t need to be maintained. So writing the tests first, before you write the implementation, gives you a clear focus on which problem you need to solve next. Writing only code that is necessary, and not accidentally more, is maybe an underestimated side effect that TDD can provide you with.
They have a positive effect on your design. To me, understanding this part turned on a light bulb and made me really appreciate the whole testing thing. When you write your implementations around very focused test scenarios, your code will most likely turn out to be much more compartmentalized and modular. Since we are all friends of DRY—“Don’t repeat yourself!”—and as little coupling between components in your app as possible, this is a simple but effective discipline to achieve systems which are designed well from the ground up. This aspect is the most important benefit, I think. Yes, the other ones are pretty awesome as well, but when tests also result in apps whose quality is better due to a refined design, I’d say Jackpot!
It boils down to money as well. When you have a stable app that is easy to maintain and easy to change, you will save quite a bit of money in the long run. Unnecessary complexity can haunt projects easily, and motivation won’t be on an all-time high when your team has to fight your code because it’s brittle and badly designed. Good application design can absolutely support your business goals—and vice versa. Do you want to introduce some new features that are critical to your business, but you are constantly fighting your architecture because it was built on sand? Of course not, and we all have seen lots of examples of businesses that quickly disappeared for that exact reason. Good testing habits can be an effective line of defense for such situations.
Another goal that is important is in respect to the quality of your code itself. The software you write should be easy to understand for other developers—as much as possible, at least. Your tests can really help to convey the functionality and intent of your application—and not only to other members on a team but to your future self as well. If you don’t touch a certain section of your code for quite a while, it will really be handy to refresh your memory of how and why you wrote a piece of software with the documentation that a tool such as RSpec provides—and RSpec does this really well, exceptionally actually.
Since your code will always change, refactoring your code will and should always be part of developing your software. And since change is so baked into this process, you need to make sure that these changes don’t generate unexpected side effects in surprising places. The test suite gives you a pretty tight-knit security net to feel more comfortable and free to refactor with gusto. This aspect, next to the design benefits TDD can provide you with, is my favorite benefit a test suite can help you with. Modifying and extending your code is such an essential component of innovating on your already released “product” that you need a tool that gives you as much freedom as possible with that process. I’m not sure if people who are critical of writing an extensive test suite are much concerned about this aspect.
You will have a good chance of building new stuff faster in later stages because the feedback from the test suite will give you feedback about your failures, bugs, and limitations—much faster than a human can test, of course. Plus, it will give you the confidence of working with a security net that becomes even more valuable the longer you go.
In your apps, especially if they have grown significantly, you want to be able to trust your software. 100% code coverage sounds a lot sweeter when you have a site that is a couple of years old and touched by hundreds of developers. Being able to trust the new code you introduce and building on top of that is one of the blisses of software development that money can’t buy later on.
rails new your_app -T
-T lets you skip Test Unit, the testing framework that comes with Rails.
group :development, :test do gem 'rspec-rails' end
bundle
After that we need to run a generator that comes with RSpec:
rails generate rspec:install
create .rspec create spec create spec/spec_helper.rb create spec/rails_helper.rb
What this does is set up the basic structure for your RSpec tests within Rails. As you can see from the output above, this generator initialized a spec directory with a few files that you will need later. The .rspec file is a configuration file that we won’t need to manipulate for now. I just wanted to let you know what you have in front of you. The other files are self-explanatory, but I wanted to mention their differences.
spec_helper.rb is for specs that don’t depend on Rails.rails_helper.rb, on the other hand, is for specs that do depend on it.What is not obvious is that one of these files needs to be required on top of your spec files (test files) in order to run your tests. Let’s have a quick look! When you generate a model via:
rails generate model dummy_model name:string
invoke active_record create db/migrate/20160521004127_create_dummy_models.rb create app/models/dummy_model.rb invoke rspec create spec/models/dummy_model_spec.rb
Not only will Rails have created the associated _spec.rb files for you, your specs will also automatically have require 'rails_helper' by default on top of your spec files. That means you are ready to go, right away.
require 'rails_helper' ...
So with this setup, you can test your Rails app, your models for example, and RSpec will not get confused about model classes used in Rails. This is necessary to require whenever you need stuff like ActiveRecord, ApplicationController and so on. So this is your normal scenario and therefore should be your first logical choice as a beginner.
Requiring spec_helper.rb, on the other hand, will throw an error if you write tests that include business logic from your Rails app. In that scenario, RSpec would not know what you are talking about when you want to test some Rails model, for example.
So long story super short, spec_helper does not load Rails—that’s it! Of course, you can go wild with configurations, but this is nothing I want you to be concerned about right now. Let’s focus on the basics, how to run tests and the syntax. That should suffice for starters. Let’s move on!
You are ready to run your tests. RSpec requires your test files to have a specific suffix like _spec to understand which files to run. If you use a generator, this is not a concern, but if you want to write test files on your own, this is how they need to end. So you will need to put a file like your_first_test_spec.rb in your spec directory.
Using the generator for creating a dummy model already provided us with spec/models/dummy_model_spec.rb. Not bad! One thing left to do before the tests are ready:
rake db:migrate rake db:test:prepare
These commands run your migration for the dummy model we generated above, and set up the test database with that model as well. Now we actually run the test:
rake
The rake command will run all your tests, the complete test suite. Usually you should use this command when you have finished some feature and want to exercise the whole test suite.
* Pending: (Failures listed here are expected and do not affect your suite's status) 1) DummyModel add some examples to (or delete) /Users/vis_kid/projects/rspec-test-app/rspec-dummy/spec/models/dummy_model_spec.rb # Not yet implemented # ./spec/models/dummy_model_spec.rb:4 Finished in 0.00083 seconds (files took 1.94 seconds to load) 1 example, 0 failures, 1 pending
Congratulations! You just ran your first RSpec test. Not that bad, was it? Of course, this was a dummy test for now—with dummy test code generated by Rails. The more focused version of running your tests—you have actually a lot more options than only that—is to run an individual file, for example. Like this:
bundle exec rspec spec/models/dummy_model_spec.rb
This will only run a single test file instead of the whole test suite. With larger applications that depend on a high amount of test files, this will become a real time saver. But in terms of saving time and test specificity, this is only scratching the surface, to be frank. I think we will cover more of how to shave off a significant amount of time while testing in the third article in this series. Let’s see how far we get!
The other way to exercise the whole test suite is by simply running rspec—with or without bundle exec, depending on your setup.
bundle exec rspec
One more thing I should mention before we move on, you can also run only a specific subset of tests. Say you only want to run all of your tests for your model code:
bundle exec rspec spec/models
Easy as that!
I recommend that we start with the bare basics and look into a few more options that RSpec provides in the next two articles. Let’s have a look at the basic structure of a test and dive into more advanced waters when we've got this one out of the way.
describeThis will be your bread and butter because it organizes your specs. You can reference strings or classes themselves:
describe User do end describe 'Some string' do end
describe sections are the basic building blocks to organize your tests into logical, coherent groups to test. Basically, a scope for different parts of your application that you want to test.
describe User do ... end describe Guest do ... end describe Attacker do ... end
A good tip is to tighten your scope even more. Since some classes will grow quite significantly, it’s not a good idea to have all the methods you want to test for one class in a single describe block. You can create multiple of these blocks, of course, and focus them around instance or class methods instead. To make your intent clearer, all you need is to provide the class name with an extra string that references the method you want to test.
describe Agent, '#favorite_gadget' do ... end describe Agent, '#favorite_gun' do ... end describe Agent, '.gambler' do ... end
That way you get the best of both worlds. You encapsulate related tests in their representative groups while keeping things focused and at a decent size. For users very new to Ruby land, I should mention that # simply references an instance method while the dot . is reserved for class methods. Because they are inside strings, they have no technical implications here, but they signal your intent to other developers and your future self. Don’t forget the comma after the class name—it won’t work without it! In a minute, when we get to expect, I’ll show you why this approach is super convenient.
itWithin the scope of describe groups, we use another scope of it blocks. These are made for the actual examples under test. If you want to test the instance method #favorite_gadget on the Agent class, it would look like this:
describe Agent, '#favorite_gadget' do
it 'returns one item, the favorite gadget of the agent ' do
...
end
end
The string that you provide to the it block works as the main documentation for your test. Within it, you specify exactly what kind of behavior you want or expect from the method in question. My recommendation is not to go overboard and be too verbose about it but at the same time not to be overly cryptic and confuse others with overly smart descriptions.
Think about what the smallest and simplest implementation of this part of the puzzle can and should accomplish. The better you write this part, the better the overall documentation for your app will be. Don’t rush this part because it’s just a string that can’t do any damage—at least not on the surface.
expect()Now we’re getting more to the heart of things. This method lets you verify or falsify the part of the system you want to test. Let’s go back to our previous example and see it in (limited) action:
describe Agent, '#favorite_gadget' do
it 'returns one item, the favorite gadget of the agent ' do
expect(agent.favorite_gadget).to eq 'Walther PPK'
end
end
expect() is the “new” assertion syntax of RSpec. Previously we used should instead. Different story, but I wanted to mention it in case you run into it. expect() expects that you provide it with an object and exercise whatever method under test on it. Finally, you write the asserted outcome on the right side.
You have the option to go the positive or negative route with .to eq or .not_to eq for example (eq being short for equal of course). You can always turn the logic around—whatever suits best your needs. Let’s run this nonsensical test and focus on the output that we got as a result of our test setup:
rspec spec/models/agent_spec.rb
Failures:
1) Agent#favorite_gadget returns one item, the favorite gadget of the agent
Failure/Error: expect(agent.favorite_gadget).to eq 'Walther PPK'
Reads pretty nice, doesn’t it? **"Agent#favorite_gadget returns one item, and the favorite gadget of the agent"** tells you all you need to know:
If we had left off the string that describes the method in the describe block, then the output would have been a lot less clear and readable:
describe Agent do
it 'returns one item, the favorite gadget of the agent ' do
expect(agent.favorite_gadget).to eq 'Walther PPK'
end
end
Failures:
1) Agent returns one item, the favorite gadget of the agent
Failure/Error: expect(agent.favorite_gadget).to eq 'Walther PPK'
Sure, there are other ways to circumvent and deal with this—passing this info via your it block, for example—but the other approach is just simple and works. Whatever makes your blood flow, of course!
Best practices in testing recommend that we compose our tests in four distinct phases:
These four phases are mostly for readability and to give your tests a conventional structure. It’s a so-called testing pattern, basically, a practice that the community widely agreed upon to be useful and recommended. This whole patterns topic is a deep rabbit hole, so know that I’ll leave out a bunch so as not to confuse the beginners among you to death.
During setup, you prepare the scenario under which the test is supposed to run. In most cases, this will include data needed to be ready for some kind of exercise. Little tip: don’t overcomplicate things, and set up only the minimum amount necessary to make the test work.
agent = Agent.create(name: 'James Bond') mission = Mission.create(name: 'Moonraker', status: 'Briefed')
This part actually runs the thing that you want to test in this spec. Could be as simple as:
status = mission.agent_status
Now you verify if your assertion about the test is being met or not. So you test the system against your own expectations.
expect(status).not_to eq 'MIA')
The framework takes care of memory and database cleaning issues—a reset, basically. There's nothing for you to handle at this point. The goal is to get back a pristine state to run new tests without any surprises from the currently running ones. Let’s see what this would mean in a dummy example:
describe Agent, '#favorite_gadget' do
it 'returns one item, the favorite gadget of the agent ' do
# Setup
agent = Agent.create(name: 'James Bond')
q = Quartermaster.create(name: 'Q')
q.technical_briefing(agent)
# Exercise
favorite_gadget = agent.favorite_gadget
# Verify
expect(favorite_gadget).to eq 'Walther PPK'
# Teardown is for now mostly handled by RSpec itself
end
end
As you can see, in this example we separated the exercise and verify phases clearly from each other, whilst in the other dummy examples above, expect(agent.favorite_gadget).to eq 'Walther PKK, we mixed both phases together. Both are valid scenarios and have their place. Also, the new lines help to visually separate how the test is structured.
Now comes the hard part, what to test and how. In my opinion, this is the aspect of testing that is most confusing to newcomers—and understandably so! You are new to the language and framework and often don’t even know yet what you don’t know. How do you write tests for that? Very good question.
I’ll be very frank, you don’t—most likely—and you won’t for quite a while. Getting comfortable with this stuff takes a while. When you have a mentor or attend some boot camp and such, you have the opportunity to directly learn from experienced people. In that case, your progress in this department will be different, of course.
On the other hand, if—like so many others out there—you are teaching yourself this stuff, patience will be key. Reading all the books and articles certainly gets you in the right direction, but I think that testing needs a lot of more advanced puzzle pieces in place in order for you to make complete sense and, maybe even more important, before you feel comfortable with it.
The “good” news is that this is not unusual and we all have been there. Perseverance is important. You can do this, it’s no rocket science, but it will take a while until you can write an application effectively from the other way around—from the perspective of tests, I mean. For now, keep pushing, have fun, make mistakes, write apps, copy tutorials and whatnot, until the light bulb goes off.
When you write your individual tests, you want to make their objects do the simplest thing possible to achieve your goal—highly focused tests are really key. You want to design your application via very simple steps and then follow the errors your test suite is providing you with.
Only implement what is necessary to get the app green. Not more, not less! That’s the “driven” part in test-driven development. Your work is guided by the needs of your tests.
The second article in this short series teaches you how to use various matchers that come with RSpec. It also shows you how to slice your test suite through tagging, how callbacks work, and how to extract some data. We expand a little on the basic survival kit from the first article and show you enough to be dangerous without too much rope to hang yourself.
In the first article we spent quite a lot of time trying to answer the “why?” of testing. I suggest we get right back to the “how?” and spare ourselves any more context. We covered that part extensively already. Let’s see what else RSpec has to offer that you as a beginner can handle right away.
So this is going to approach the heart of things. RSpec provides you with a ton of so-called matchers. These are your bread and butter when you write your expectations. So far you have seen .to eq and .not_to eq. But there is a much bigger arsenal to write your specs. You can test to raise errors, for truthy and falsy values, or even for specific classes. Let’s run down a few options to get you started:
.to eq.not_to eq This tests for equivalence.
... it 'some clever description' do expect(agent.enemy).to eq 'Ernst Stavro Blofeld' expect(agent.enemy).not_to eq 'Winnie Pooh' end ...
To keep things short, I packed two expect statements within one it block. It is good practice, though, to test only a single thing per test. This keeps things a lot more focused, and your tests will end up less brittle when you change things.
.to be_truthy.to be true... it 'some clever description' do expect(agent.hero?).to be_truthy expect(enemy.megalomaniac?).to be true end ...
The difference is that be_truthy is true when it’s not nil or false. So it will pass if the result is neither of these two—kind of “true-like”. .to be true on the other hand only accepts a value that is true and nothing else.
.to be_falsy.to be false... it 'some clever description' do expect(agent.coward?).to be_falsy expect(enemy.megalomaniac?).to be false end ...
Similar to the two examples above, .to be_falsy expects either a false or a nil value, and .to be false will only do a direct comparison on false.
.to be_nil.to_not be_nilAnd last but not least, this tests exactly for nil itself. I spare you the example.
.to match()I hope you already had the pleasure of looking into regular expressions. If not, this is a sequence of characters with which you can define a pattern that you put between two forward slashes to search strings. A regex can be very handy if you want to look for broader patterns that you could generalize in such an expression.
...
it 'some clever description' do
expect(agent.number.to_i).to match(/\d{3}/)
end
...
Suppose we're dealing with agents like James Bond, 007, who are assigned three-digit numbers. Then we could test for it this way—primitively here, of course.
><<=>=Comparisons come in handy more often than one might think. I assume the examples below will cover what you need to know.
... it 'some clever description' do ... expect(agent.number).to be < quartermaster.number expect(agent.number).to be > m.number expect(agent.kill_count).to be >= 25 expect(quartermaster.number_of_gadgets).to be <= 5 end ...
Now, we are getting somewhere less boring. You can also test for classes and types:
.to be_an_instance_of.to be_a.to be_an... it 'some clever description' do mission = Mission.create(name: 'Moonraker') agent = Agent.create(name: 'James Bond') mission.agents << agent expect(@mission.agents).not_to be_an_instance_of(Agent) expect(@mission.agents).to be_a(ActiveRecord::Associations::CollectionProxy) end ...
In the dummy example above, you can see that a list of agents that are associated with a mission are not of class Agent but of ActiveRecord::Associations::CollectionProxy. What you should take away from this one is that we can easily test for classes themselves while staying highly expressive. .to be_a and .to be_an do one and the same thing. You have both options available to keep things readable.
Testing for errors is also massively convenient in RSpec. If you are super fresh to Rails and not sure yet which errors the framework can throw at you, you might not feel the need to use these—of course, that makes total sense. At a later stage in your development, you will find them very handy, though. You have four ways to deal with them:
.to raise_errorThis is the most generic way. Whatever error is raised will be cast in your net.
.to raise_error(ErrorClass)That way you can specify exactly which class the error should come from.
.to raise_error(ErrorClass, "Some error message")This is even more fine grained since you not only mention the class of the error but a specific message that should be thrown with the error.
.to raise_error("Some error message)Or you just mention the error message itself without the error class. The expect part needs to be written a little bit differently, though—we need to wrap the part under text in a code block itself:
...
it 'some clever description' do
agent = Agent.create(name: 'James Bond')
expect{agent.lady_killer?}.to raise_error(NoMethodError)
expect{double_agent.name}.to raise_error(NameError)
expect{double_agent.name}.to raise_error("Error: No double agents around")
expect{double_agent.name}.to raise_error(NameError, "Error: No double agents around")
end
...
.to start_with.to end_withSince we often deal with collections when building web apps, it’s nice to have a tool to peek into them. Here we added two agents, Q and James Bond, and just wanted to know who comes first and last in the collection of agents for a particular mission—here Moonraker.
... it 'some clever description' do moonraker = Mission.create(name: 'Moonraker') bond = Agent.create(name: 'James Bond') q = Agent.create(name: 'Q') moonraker.agents << bond moonraker.agents << q expect(moonraker.agents).to start_with(bond) expect(moonraker.agents).to end_with(q) end ..
.to includeThis one is also helpful to check the contents of collections.
... it 'some clever description' do mission = Mission.create(name: 'Moonraker') bond = Agent.create(name: 'James Bond') mission.agents << bond expect(mission.agents).to include(bond) end ...
These predicate matchers are a feature of RSpec to dynamically create matchers for you. If you have predicate methods in your models, for example (ending with a question mark), then RSpec knows that it should build matchers for you that you can use in your tests. In the example below, we want to test if an agent is James Bond:
class Agent < ActiveRecord::Base
def bond?
name == 'James Bond' && number == '007' && gambler == true
end
...
end
Now, we can use this in our specs like so:
... it 'some clever description' do agent = Agent.create(name: 'James Bond', number: '007', gambler: true) expect(agent).to be_bond end it 'some clever description' do agent = Agent.create(name: 'James Bond') expect(agent).not_to be_bond end ...
RSpec lets us use the method name without the question mark—to form a better syntax, I suppose. Cool, ain’t it?
let and let! might look like variables at first, but they are actually helper methods. The first one is lazily evaluated, which means that it is only run and evaluated when a spec actually uses it, and the other let with the bang(!) is run regardless of being used by a spec or not. Both versions are memoized, and their values will be cached within the same example scope.
describe Mission, '#prepare', :let do
let(:mission) { Mission.create(name: 'Moonraker') }
let!(:bond) { Agent.create(name: 'James Bond') }
it 'adds agents to a mission' do
mission.prepare(bond)
expect(mission.agents).to include bond
end
end
The bang version that is not lazily evaluated can be time-consuming and therefore costly if it becomes your fancy new friend. Why? Because it will set up this data for each test in question, no matter what, and might eventually end up being one of these nasty things that slow down your test suite significantly.
You should know this feature of RSpec since let is widely known and used. That being said, the next article will show you some issues with it that you should be aware of. Use these helper methods with caution, or at least in small doses for now.
RSpec offers you the ability to declare the subject under test very explicitly. There are better solutions for this, and we will discuss the downsides of this approach in the next article when I show a few things you generally want to avoid. But for now, let’s have a look at what subject can do for you:
describe Agent, '#status' do
subject { Agent.create(name: 'Bond') }
it 'returns the agents status' do
expect(subject.status).not_to be 'MIA'
end
end
This approach can, on the one hand, help you with reducing code duplication, having a protagonist declared once in a certain scope, but it can also lead to something called a mystery guest. This simply means that we might end up in a situation where we use data for one of our test scenarios but have no idea anymore where it actually comes from and what it is comprised of. More on that in the next article.
In case you are not aware of callbacks yet, let me give you a brief heads up. Callbacks are run at certain specific points in the lifecycle of code. In terms of Rails, this would mean that you have code that is being run before objects are created, updated, destroyed, etc.
In the context of RSpec, it’s the lifecycle of tests being run. That simply means that you can specify hooks that should be run before or after each test is being run in the spec file, for example—or simply around each test. There are a few more fine-grained options available, but I recommend we avoid getting lost in the details for now. First things first:
before(:each)This callback is run before each test example.
describe Agent, '#favorite_gadget' do
before(:each) do
@gagdet = Gadget.create(name: 'Walther PPK')
end
it 'returns one item, the favorite gadget of the agent ' do
agent = Agent.create(name: 'James Bond')
agent.favorite_gadgets << @gadget
expect(agent.favorite_gadget).to eq 'Walther PPK'
end
...
end
Let’s say you would need a certain gadget for every test you run in a certain scope. before lets you extract this into a block and prepares this little snippet for you conveniently. When you set up data that way, you have to use instance variables, of course, to have access to it among various scopes.
Don’t get fooled by convenience in this example. Just because you can do this kind of stuff does not mean you should. I want to avoid going into AntiPattern territory and confuse the hell out of you, but on the other hand, I want to explain the downsides to these simple dummy exercises a bit as well.
In the example above, it would be much more expressive if you set up the needed objects on a test-by-test basis. Especially on larger spec files, you can quickly lose sight of these little connections and make it harder for others to piece together these puzzles.
before(:all)This before block runs only once before all the other examples in a spec file.
describe Agent, '#enemy' do
before(:all) do
@main_villain = Villain.create(name: 'Ernst Stavro Blofeld')
@mission = Mission.create(name: 'Moonraker')
@mission.villains << @main_villain
end
it 'returns the main enemy Bond has to face in his mission' do
agent = Agent.create(name: 'James Bond')
@mission.agents << agent
expect(agent.enemy).to eq 'Ernst Stavro Blofeld'
end
...
end
When you remember the four phases of test, before blocks sometimes are helpful in setting something up for you that needs to be repeated on a regular basis—probably stuff that is a bit more meta in nature.
after(:each) and after(:all) have the same behavior but are simply run after your tests have been executed. after is often used for cleaning up your files, for example. But I think it’s a bit early to address that. So commit it to memory, know that it’s there in case you start needing it, and let’s move on to explore other, more basic things.
All of these callbacks can be placed strategically to fit your needs. Place them in any describe block scope that you need to run them—they don’t have to necessarily be placed on top of your spec file. They can easily be nested way inside your specs.
describe Agent do
before(:each) do
@mission = Mission.create(name: 'Moonraker')
@bond = Agent.create(name: 'James Bond', number: '007')
end
describe '#enemy' do
before(:each) do
@main_villain = Villain.create(name: 'Ernst Stavro Blofeld')
@mission.villains << @main_villain
end
describe 'Double 0 Agent with associated mission' do
it 'returns the main enemy the agent has to face in his mission' do
@mission.agents << @bond
expect(@bond.enemy).to eq 'Ernst Stavro Blofeld'
end
end
describe 'Low-level agent with associated mission' do
it 'returns no info about the main villain involved' do
some_schmuck = Agent.create(name: 'Some schmuck', number: '1024')
@mission.agents << some_schmuck
expect(some_schmuck.enemy).to eq 'That’s above your paygrade!'
end
end
...
...
...
end
end
As you can observe, you can place callback blocks at any scope to your liking, and go as deep as you need. The code in the callback will be executed within the scope of any describe block scope. But a little bit of advice: if you feel the need of nesting too much and things seem to get a little bit messy and complicated, rethink your approach and consider how you could simplify the tests and their setup. KISS! Keep it simple, stupid. Also, pay attention to how nicely this reads when we force these tests to fail:
Failures:
1) Agent#enemy Double 0 Agent with associated mission returns the main enemy the agent has to face in his mission
Failure/Error: expect(@bond.enemy).to eq 'Ernst Stavro Blofeld'
expected: "Ernst Stavro Blofeld"
got: "Blofeld"
2) Agent#enemy Low-level agent with associated mission returns no info about the main villain involved
Failure/Error: expect(some_schmuck.enemy).to eq 'That’s above your paygrade!'
expected: "That’s above your paygrade!"
got: "Blofeld"
Let’s also have a quick look at what generators are provided by RSpec for you. You have already seen one when we used rails generate rspec:install. This little fella made setting up RSpec for us quick and easy. What else do we have?
rspec:modelWant to have another dummy model spec?
rails generate rspec:model another_dummy_model
create spec/models/another_dummy_model_spec.rb
Quick, isn’t it? Or a new spec for a controller test, for example:
rspec:controllerrails generate rspec:controller dummy_controller
spec/controllers/dummy_controller_controller_spec.rb
rspec:viewThe same works for views, of course. We won’t be testing any views like that, though. Specs for views give you the least bang for the buck, and it is totally sufficient in probably almost any scenario to indirectly test your views via feature tests.
Feature tests are not a specialty of RSpec per se and are more suited to another article. That being said, if you are curious, check out Capybara, which is an excellent tool for that kind of thing. It lets you test whole flows that exercise multiple parts of your app coming together—testing complete features while simulating the browser experience. For example, a user who pays for multiple items in a shopping cart.
rspec:helperThe same generator strategy lets us also place a helper without much fuss.
rails generate rspec:helper dummy_helper
create spec/helpers/dummy_helper_helper_spec.rb
The double helper_helper part was not an accident. When we give it a more “meaningful” name, you will see that RSpec just attaches _helper on its own.
rails generate rspec:helper important_stuff
create spec/helpers/important_stuff_helper_spec.rb
No, this directory is not a place to hoard your precious helper methods that come up while refactoring your tests. These would go under spec/support, actually. spec/helpers is for the tests that you should write for your view helpers—a helper like set_date would be a common example. Yes, complete test coverage of your code should also include these helper methods. Just because they often seem small and trivial doesn’t mean that we should overlook them or ignore their potential for bugs we want to catch. The more complex the helper actually turns out, the more reason you should have to write a helper_spec for it!
Just in case you start playing around with it right away, keep in mind that you need to run your helper methods on a helper object when you write your helper tests in order to work. So they can only be exposed using this object. Something like this:
describe '#set_date' do ... helper.set_date ... end ...
You can use the same kind of generators for feature specs, integration specs and mailer specs. These are out of our scope for today, but you can commit them to memory for future use:
The specs we created via the generator above are ready to go, and you can add your tests in there right away. Let’s have a tiny look at a difference between specs, though:
require 'rails_helper'
RSpec.describe DummyModel, type: :model do
pending "add some examples to (or delete) #{__FILE__}"
end
require 'rails_helper' RSpec.describe DummyControllerController, type: :controller do end
require 'rails_helper'
RSpec.describe DummyHelperHelper, type: :helper do
pending "add some examples to (or delete) #{__FILE__}"
end
It doesn’t need a wunderkind to figure out that they all have different types. This :type RSpec metadata gives you an opportunity to slice and dice your tests across file structures. You can target these tests a bit better that way. Say you want to have some sort of helpers only loaded for controller specs, for example. Another example would be that you want to use another directory structure for specs that RSpec does not expect. Having this metadata in your tests makes it possible to continue to use RSpec support functions and not trip up the test suite. So you are free to use whatever directory structure works for you if you add this :type metadata.
Your standard RSpec tests do not depend on that metadata, on the other hand. When you use these generators, they will be added for free, but you can totally avoid them as well if you don’t need them.
You can also use this metadata for filtering in your specs. Say you have a before block that should run only on model specs, for example. Neat! For bigger test suites, this might come in very handy one day. You can filter which focused group of tests you want to run—instead of executing the whole suite, which might take a while.
Your options extend beyond the three tagging options above, of course. Let’s learn more about slicing and dicing your tests in the next section.
When you amass a bigger test suite over time, it won’t just be enough to run tests in certain folders to run RSpec tests quickly and efficiently. What you want to be able to do is run tests that belong together but might be spread across multiple directories. Tagging to the rescue! Don’t get me wrong, organizing your tests smartly in your folders is key as well, but tagging takes this just a bit further.
You are giving your tests some metadata as symbols like “:wip”, “:checkout”, or whatever fits your needs. When you run these focused groups of tests, you simply specify that RSpec should ignore running other tests this time by providing a flag with the name of the tags.
describe Agent, :wip do
it 'is a mess right now' do
expect(agent.favorite_gadgets).to eq 'Unknown'
end
end
rspec --tag wip
Failures:
1) Agent is a mess right now
Failure/Error: expect(agent.favorite_gadgets).to eq 'Unknown'
...
You could also run all kinds of tests and ignore a bunch of groups that are tagged a certain way. You just provide a tilde (~) in front of the tag name, and RSpec is happy to ignore these tests.
rspec --tag ~wip
Running multiple tags synchronously is not a problem either:
rspec --tag wip --tag checkout rspec --tag ~wip --tag checkout
As you can see above, you can mix and match them at will. The syntax is not perfect—repeating --tag is maybe not ideal—but hey, it’s no biggie either! Yes, all of this is a bit more extra work and mental overhead when you compose the specs, but on the flip side, it really provides you with a powerful ability to slice up your test suite on demand. On bigger projects, it can save you a ton of time that way.
What you've learned so far should equip you with the absolute basics to play with tests on your own—a survival kit for beginners. And really do play and make mistakes as much as you can. Take RSpec and the whole test-driven thingie for a spin, and don’t expect to write quality tests right away. There are still a couple of pieces missing before you will feel comfortable and before you will be effective with it.
For me, this was a bit frustrating in the beginning because it was hard to see how to test something when I hadn’t yet implemented it and didn’t fully understand how it would behave.
Testing really proves whether you understand a framework like Rails and know how the pieces fit together. When you write tests, you will need to be able to write expectations for how a framework should behave.
That is not easy if you're just starting out with all of this. Dealing with multiple domain-specific languages—here RSpec and Rails, for example—plus learning the Ruby API can be confusing as hell. Don’t feel bad if the learning curve seems daunting; it will get easier if you stick with it. Making this light bulb go off won’t happen over night, but to me, it was very much worth the effort.
Have you heard about the new Twitter Dashboard? Wondering how to use it to manage your Twitter presence? If you’re using Twitter for a business of any size, you’ll want to check out the new features Twitter Dashboard offers. In this article, you’ll discover how to use Twitter Dashboard to better manage your Twitter marketing. [...]
This post How to Use the Twitter Dashboard first appeared on .
- Your Guide to the Social Media Jungle
