Rspec or Cucumber?


Cucumber is a tool that executes plain-text functional descriptions as automated tests.

Cucumber is intended to be used for acceptance tests. Cucumber steps include checks for
rendering and redirection and also view content — in other words,
full coverage is still maintained.

Cucumber functionality

1) Define feature scenario in cucumber for what my end goal is for the functionality
2) Start implementing each step of the feature scenario
3) For each part of functionality required that is in a model, BDD that with rspec
4) repeat until functionality is complete

That way you have Integration testing covered for an end to end request in your application, and each part of your model can be built and tested in isolation as well using rspec or test unit.

The only downside I’ve seen with cucumber so far is, since it’s full
stack, you need to get your data setup correctly.  For my project the
data relationship are complex so I’ve had to resort to some heavy handed
data manipulation in the setup (e.g. Model.delete_all).


RSpec is a behavior driven development (BDD) framework for the Ruby programming language, inspired by JBehave.

Difference between Rspec or Cucumber?

Cucumber to drive the main features and RSpec to flush out
more difficult cases.  Just today I got into the cycle of:

Cucumber is intended to be used for acceptance tests, and rspec for unit tests.

You should be using both. Well either that or cucumber and test unit.

Cucumber takes care of your integration/acceptance testing, and rspec/test unit should take care of your model unit tests. A typical workflow for me with this is,

What is the difference between a class and a module?

Modules are collections of methods and constants. They cannot generate instances. Classes may generate instances (objects), and have per-instance state (instance variables).

Modules may be mixed in to classes and other modules. The mixed-in module’s constants and methods blend into that class’s own, augmenting the class’s functionality. Classes, however, cannot be mixed in to anything.

A class may inherit from another class, but not from a module.

A module may not inherit from anything.

Why testing?

Confidence=>Verification that our system behaves as it is suppose to. this can be done manually or can be automated. Automated testing is less painful and much easier because it shortened feedback loop make improving our design.

There are two fundamental purposes of testing:

1.verifying procurement specifications
2. managing risk.

First, testing is about verifying that what was specified is what was
delivered: it verifies that the product (system) meets the functional, performance,
design, and implementation requirements identified in the procurement specifications.
Second, testing is about managing risk for both the acquiring agency and the system’s
vendor/developer/integrator.  The testing program is used to identify when the work has
been “completed” so that the contract can be closed, the vendor paid, and the system
shifted by the agency into the warranty and maintenance phase of the project.

What testing do for us?

  • Testing improves your designs. Each target object that you test must have at least two clients: your production code, and your test case. These clients force you to decouple your code. Testing also encourages and rewards smaller, simpler methods.
  • Testing reduces unnecessary code. When you write your test cases first, you get in the habit of writing only enough code to make the test case pass. You reduce the temptation to code features because you might need them later.
  • Test-first development is motivating. Each test case that you write establishes a small problem. Solving that problem with code is rewarding and motivating. When I do test-driven development, the hours fly by.
  • Testing allows more freedom. If you have test cases that will catch likely errors, you’ll find that you’re more willing to make improvements to your code.

What is the difference between _url and _path

I was wondering why some people are using _path and why some use _url. For example, if you have a Post resource you can write the following in your view:

  [%= link_to 'List of posts', posts_path %]

or the following in the controller:

  redirect_to posts_url

Why should I use _url in the controller. I have used _path and it seems to work.

This is an explanation I found in a forum and I quote:

*_path are for views because ahrefs are implicitly linked to the current URL. So it’d be a waste of bytes to repeat it over and over. In the controller, though, *_url is needed for redirect_to because the HTTP specification mandates that the Location: header in 3xx redirects is a complete URL

Rails Filters: Before, After, and Around Filters

Filters are methods that are run before, after or “around” a controller action.

Filters are inherited, so if you set a filter on ApplicationController, it will be run on every controller in your application.

Before filters may halt the request cycle. A common before filter is one which requires that a user is logged in for an action to be run.

Before filters are run on requests before the request gets to the controller’s action. It can return a response itself and completely bypass the action.

The most common use of before filters is validating a user’s authentication before granting them access to the action designated to handle their request. I’ve also seen them used to load a resource from the database, check permissions on a resource, or manage redirects under other circumstances.

After filters are run after the action completes. It can modify the response. Most of the time if something is done in an after filter, it can be done in the action itself, but if there is some logic to be run after running any of a set of actions, then an after filter is a good place to do it.

Generally, I’ve seen after and around filters used for logging.

Around filters may have logic before and after the action being run. It simply yields to the action in whatever place is necessary. Note that it doesn’t need to yield to the action and may run without doing so like a before filter.

You can use around filters for exception handling, setup and teardown, and a myriad of other cases.

The Difference Between Symbols and Strings

The truth of the matter is that Symbols are Strings, just with an important difference, Symbols are immutable. Mutable objects can be changed after assignment while immutable objects can only be overwritten. Ruby is quite unique in offering mutable Strings, which adds greatly to its expressiveness. However mutable Strings can have their share of issues in terms of creating unexpected results and reduced performance. It is for this reason Ruby also offers programmers the choice of Symbols.

So, how flexible are Symbols in terms of representing data? The answer is just as flexible as Strings.