msuzoagu

git branch -m old_branch new_branch         # Rename branch locally    
git push origin :old_branch                 # Delete the old branch    
git push --set-upstream origin new_branch   # Push the new branch, set local branch to track the new remote

msuzoagu

msuzoagu

# In app/helpers/users_helper.rb

require_relative 'users_helper/greet'

module UsersHelper
  module Internals
  end
  private_constant :Internals
  include Internals

msuzoagu

#Model 

@user.should have(1).error_on(:username) # Checks whether there is an error in username 
@user.errors[:username].should include("can't be blank")  # check for the error message 

#Rendering
response.should render_template(:index)

#Redirecting 
response.should redirect_to(movies_path)

msuzoagu

# This file is copied to spec/ when you run 'rails generate rspec:install'

if ENV['coverage'] == 'on'
  require 'simplecov'
  SimpleCov.start 'rails' do
    minimum_coverage 100
  end
end

ENV['RAILS_ENV'] ||= 'test'

msuzoagu

1. Your class can be no longer than 100 lines of code.
2. Your methods can be no longer than five lines of code.
3. You can pass no more than four parameters and you can’t just make it one big hash.
4. When a call comes into your Rails controller, you can only instantiate one object to do whatever it is that needs to be done. And your view can only know about one instance variable.

You can break these rules if you can talk your pair into agreeing with you.

msuzoagu

<div>
  <h1>A Sinatra app to access Google+</h1>
  <p>I'm sorry but the "The Sinatra app to access Google+" Web Service is not accessible from the folder you typed in.</p>
  <p>The correct URL is: <a href="http://sinatragplus.heroku.com/">http://sinatragplus.heroku.com/</a></p>
  <p><a href="/">Back</a></p>
</div>
<div id="footer">
  <p><b>A Fun Sinatra App for Google+ by RubyLearning 20 Sept. 2011</b>.</p>
</div>

msuzoagu

##Introduction

One definition of unit testing is the process of taking the smallest piece of testable code in an application, isolating it from the remainder of your codebase and determining if it behaves exactly as expected. In this section, we'll be taking a look at how to unit test Backbone applications using a popular JavaScript testing framework called Jasmine from Pivotal Labs.

For an application to be considered 'well'-tested, distinct functionality should ideally have its own separate unit tests where it's tested against the different conditions you expect it to work under. All tests must pass before functionality is considered 'complete'. This allows developers to both modify a unit of code and it's dependencies with a level of confidence about whether these changes have caused any breakage.

As a basic example of unit testing is where a developer may wish to assert whether passing specific values through to a sum function results in the correct output being re

msuzoagu

# Application
class App < Sinatra::Base
  set :hi, "Hello"
  
  configure :test do
    set :hi, "Hello There!"
  end
end

# Registering a extention

msuzoagu

If you're writing web applications with Ruby there comes a time when you might need something a lot simpler, or even faster, than Ruby on Rails or the Sinatra micro-framework. Enter Rack.

Rack describes itself as follows:

Rack provides a minimal interface between webservers supporting Ruby and Ruby frameworks.

Before Rack came along Ruby web frameworks all implemented their own interfaces, which made it incredibly difficult to write web servers for them, or to share code between two different frameworks. Now almost all Ruby web frameworks implement Rack, including Rails and Sinatra, meaning that these applications can now behave in a similar fashion to one another.

At it's core Rack provides a great set of tools to allow you to build the most simple web application or interface you can. Rack applications can be written in a single line of code. But we're getting ahead of ourselves a bit.