We recently ran into this problem and came up with a neet solution where the client side templates can also be rendered server side.

There are two parts to the implementation. First, a method that can take a jade partial and its local variables, compile and evaluate it. Second, a view that calls out to that method and provides the template and the necessary local variables.

Part 1, the application_helper.rb

require 'tilt-jade/jade_js'

module ApplicationHelper
  def html_from_jade_template(partial, options={})
    data = File.open(\
            Rails.root.join("app", "assets", "templates", "#{partial}.js.jst.jade"\
            ))
    compiled = JadeJs.compile(data, locals: {}, client: true, compileDebug: false)

    raw(JadeJs::Source.context.eval("(#{compiled})(#{options[:locals].to_json}, \
        jade.runtime.attrs, jade.runtime.escape, jade.runtime.rethrow, \
        jade.runtime.merge)" \
        ))
  end
end

The method is pretty straight forward, it loads the template from the assets/template directory, compiles it and then evals it with the provided locals. The output is raw html that can be included in your view.

Part 2, a view that requests the compiled and eval’d templates from the server

- body = "This content comes from the server. Remove the param from the url or toggle \
          with the link in the upper right."
#menu
  = html_from_jade_template("home/menu", locals: {items: [{title: "Server"}, \
    {title: "Side"}, {title: "Rendered"}]})
#content
  = html_from_jade_template("home/content", locals: {body: body })

Here the main thing is the call to the method in application helper that will produce the raw html given a template name and the necessary local variables.

That is pretty much it. It may take a little bit to figure out the requirements for the local variables in your template, especially since jade is very strict about them. If it can’t find one it will not compile.

I’ve put an example app on github with the complete source code for this post.

The post How to render jade templates on the server appeared first on Pivotal Labs.

The only caveat is you have to set an expectation that your mock get’s called, otherwise if it never gets executed the test will also never fail.

Step by Step

1) Set up the spy on the method for which you want to test the params.
2) Set up the expectation to compare a param to an expected value.

spyOn(App.Views.MasterView.prototype, 'initialize').andCallFake(function() {
 expect(arguments[0].template).toEqual(JST['my_templates/simple_view']);
});

3) Call something that should call the method under test with the correct params.

var router = new App.Routers.ViewRouter;
router.simpleViewInit();

4) Set up an expecatation that makes sure the method under test get’s actually called.

expect(App.Views.MasterView.prototype.initialize).toHaveBeenCalled();

Here you go, now it is easy to test if a method is called with the expected param(s).

The complete test.

describe('App.Routers.ViewRouter', function() {
  beforeEach(function() {
    Backbone.history.start();
  });

  afterEach(function() {
    Backbone.history.stop();
  });

    describe('#simpleViewInit', function() {
        it('call initialize on the MasterView with the simple_view template', function() {
        spyOn(App.Views.MasterView.prototype, 'initialize').andCallFake(function() {
             expect(arguments[0].template).toEqual(JST['my_templates/simple_view']);
          });
          var router = new App.Routers.ViewRouter;
          router.simpleViewInit();

         expect(App.Views.MasterView.prototype.initialize).toHaveBeenCalled();
        });
    });
});

The code that is under test.

App.Routers.ViewRouter = App.Routers.BaseRouter.extend(
{
    routes: {
        'example1': 'example1'
    },

    initialize: function() {
        ...
    },

    simpleViewInit: function() {
        this.simpleViewRecord = new App.Models.SimpleViewRecord();
        this.simpleView = new App.Views.MasterView({
            el: '#view_element',
            model: this.simpleView,
            template: JST[''my_templates/simple_view''],
            state: 'expired'
        });

        this.simpleViewInit.fetch({
            success: function(model) {
              model.trigger('change');
            }, silent: true
        });
    }
});

The post Jasmine Testing: Param(s) passed to a method. appeared first on Pivotal Labs.

• anybody seen old content showing up on heroku at various points in time (especially at night)?
  • crickets …

interesting

• rake execute takes a hash, rake invoke takes an ordered list
• http://join.me is a cool tool for interactive screen sharing
• don’t use anonymous iframes for ajax file upload, use a class or id,
  • we saw weird issues with a chat provider who uses an anonymous iframe which was getting all our file upload info

The post [Standup] [Boulder] heroku and the crickets appeared first on Pivotal Labs.

jquery plugins tend to mess with your markup and force it into a specific layout
which can break your behaviour

acceptance vs. non acceptance rspec

When running regular rspec tests and acceptance test combined slow build time were observed,
breaking them out into different builds resulted in a 25% speed up
(combined 21 min, only rspec 5min, acceptance 10min)

• possible help: leave transactional_fixtures as true for acceptance
  supported by forcing one db connection as described here:

  http://blog.plataformatec.com.br/2011/12/three-tips-to-improve-the-performance-of-your-test-suite/

• reopening the rspec config block in the acceptance helper can have unintended side effects, if you are running
  units specs and acceptance specs together

The post [Standup] [Boulder] Make your own carousel appeared first on Pivotal Labs.

The post p3p headers to play with IE to keep cookies appeared first on Pivotal Labs.

It is actually not that hard and there are resources all over the inter tubes, you just have to find them.
For the sake of saving myself and some fellow programmers some time I will summarize the process we followed.

First, you need to make sure to have the fixture_builder, database_cleaner and while we’re at it headless gems installed.
Then the bulk of the work happens in acceptance_helper.rb, spec_helper.rb and fixture_builder.rb.

Details on what is in them are below. There are some notable things which I mention in context with the code.

spec_helper.rb

If you need you fixtures loaded in a particular order
you can load them in that order by specifying them as argument for the config.global_fixtures variable in spec_helper.

ENV["RAILS_ENV"] ||= 'test'
require File.expand_path("../../config/environment", __FILE__)
require 'rspec/rails'

Dir[Rails.root.join("spec/support/**/*.rb")].each {|f| require f}

RSpec.configure do |config|

  config.include ObjectCreationHelper
  config.include ObjectCreationMethods
  config.mock_with :rspec

  config.global_fixtures = :all

  # Remove this line if you're not using ActiveRecord or ActiveRecord fixtures
  config.fixture_path = "#{::Rails.root}/spec/fixtures"

  # If you're not using ActiveRecord, or you'd prefer not to run each of your
  # examples within a transaction, remove the following line or assign false
  # instead of true.
  config.use_transactional_fixtures = true

  config.before(js: nil) do
    config.use_transactional_fixtures = true
  end

end

accptance_helper.rb

Here headless (enables running selenium tests on a ci-server without a browser) and data_base cleaner are set up.
Database_cleaner will clean everything in the specified interval (in my case after each test) unless tables are specified in the “except” option for the database_cleaner strategy.
It is important to turn transactional fixtures off before running specs that require js and turn them back on after they have run
to ensure rspec spec still runs, assuming that there are spec files that have both test that require js and some that don’t require js.

require 'spec_helper'
require 'capybara/rspec'
require 'capybara/rails'
require 'database_cleaner'
require 'headless'

headless = Headless.new
headless.start

at_exit do
  unless ENV['RUNNING_CI']
    headless.destroy
  end
end

def build_fixtures
  Fixtures.reset_cache
  fixtures_folder = File.join(Rails.root.to_s, 'spec', 'fixtures')
  fixtures = Dir[File.join(fixtures_folder, '*.yml')].map { |f| File.basename(f, '.yml') }
  DatabaseCleaner.clean
  Fixtures.create_fixtures(fixtures_folder, fixtures)
end

RSpec.configure do |config|
  config.before(:suite) do
    DatabaseCleaner.strategy = :truncation, {:except => %w[ ]}
    DatabaseCleaner.clean_with(:truncation)
  end

  # before each test that requires js, turn transactional fixtures off
  # build the fixtures and start the db cleaner
  config.before(js: true) do
    config.use_transactional_fixtures = false
    build_fixtures()
    DatabaseCleaner.start
  end

  # after each spec with js, turn transactional fixtures back on
  # rebuild fixtures
  config.after(:each, js: true) do
    config.use_transactional_fixtures = true
    build_fixtures()
  end
end

fixture_builder.rb

Pretty straight forward, some clean up and checking if fixtures need rebuilding. Since database_cleaner will try to clean all exisiting tables
it is important to exclude database views specifically.

FixtureBuilder::Configuration.class_eval do

  def rebuild_fixtures?
    (@file_hashes != read_config) || Dir.glob('spec/fixtures/**/*.yml').empty?
  end

  def files_to_check
    @files_to_check ||= []
  end

  def delete_tables
    ActiveRecord::Base.connection.execute('SET FOREIGN_KEY_CHECKS=0')
    tables.each { |t| ActiveRecord::Base.connection.delete(delete_sql % ActiveRecord::Base.connection.quote_table_name(t)) }
  ensure
    ActiveRecord::Base.connection.execute('SET FOREIGN_KEY_CHECKS=1')
  end

end

FixtureBuilder.configure do |builder|
  builder.files_to_check = Dir["spec/support/fixture_builder.rb"]
  builder.skip_tables += ["current_post_stats_view"]
  builder.factory do

    united_states = Country.create! :name => "United States", :country_code => "US"
    Country.create! :name => "Canada", :country_code => "CA"

    admin_user = User.create! do |user|
      user.first_name = "Admin"
      user.last_name = "User"
      user.email = "admin@super_site_.com"
      user.password = "password"
      user.password_confirmation = "password"
      user.role = "admin"
    end
    name("admin", admin_user)

  end
end

The post Fixture builder and rspec-acceptance appeared first on Pivotal Labs.