CR: JamesM


Well when I’m working in the git repo, I don’t know who is going to code review it, so I end up having to add CR: JamesM to several commits. It can be done with rebase -i, but it is several steps per commit. I could use git-notes, but that doesn’t follow the format that we like (it puts Notes: in). Because this is a local repo only, changing the commit history is not a big deal. After some searching I found the way:

git filter-branch --msg-filter 'cat && echo "CR: REVIEWER"' p4/master~1..HEAD


This little beauty will append CR: REVIEWER to all of the commits from the master to the current head (all of the local commits).

So one of the problems I had recently was how to update the gems that are checked into source. One of the other devs wanted to use multi-line strings in cucumber and found that it didn’t work with cuke4duke until cucumber-0.4.4. We had 0.4.2. So what I needed was an easy way for the other devs to be able to update the gems without relying on jruby being “installed” on the machine. Since these are java guys, ant seemed the best solution.

Here is the ant task I used:

<path id="jruby.classpath">
	<fileset dir="jruby-lib">
		<include name="**/*.jar" />
		<exclude name="gems/*" />
	</fileset>
</path>
<target name="update.gems" description="update the installed gems">
	<!-- this updates the gems on the system -->
	<java classname="org.jruby.Main" fork="true" failonerror="true">
		<classpath refid="jruby.classpath" />
		<env key="GEM_PATH" value="jruby-lib/gems" />
		<env key="GEM_HOME" value="jruby-lib/gems" />
		<arg value="-S" />
		<arg value="gem" />
		<arg value="update" />
	</java>
	<!-- this removes any obsoleted / previous version of all gems -->
	<java classname="org.jruby.Main" fork="true" failonerror="true">
		<classpath refid="jruby.classpath" />
		<env key="GEM_PATH" value="jruby-lib/gems" />
		<env key="GEM_HOME" value="jruby-lib/gems" />
		<arg value="-S" />
		<arg value="gem" />
		<arg value="cleanup" />
	</java>
</target>

Mainline is a rails plugin which exposes your rails app via webrick to allow
testing with browser automators such as Selenium or Watir. Mainline allows
your rails actions to run in the same transaction as your unit tests so you
can use fixtures, factories, or whatever.

Basically you can now test selenium in your same transaction and don’t have to worry about rolling back your fixtures or factories.

Grab it from Github
Bug Reports at Lighthouse
Docs at RDocul.us

Ugh.

Say we have a named scope in our member object which looks like this:

class Member < ActiveRecord::Base
  named_scope :active, {:conditions => {:status => Member::STATUS_ACTIVE}}
end

There are 2 things we need to do to test them.

First would be to make sure that the conditions are the same as we think they are. This one is open for debate a bit as it is somewhat tying the implementation directly to the test.

Second, we actually have to USE the scope. Just calling Member.active does not actually use the scope. This is because named scopes can be cascaded. If I had recent scope on a member that only showed me those that signed up recently, I could actually do Member.active.recent, and it would not execute against database, it would just nest the conditions.

So how do I use the scope? Use any collection method on them. I like size, but I’m completely open to suggestions. So below is how I am testing named scopes.

class MemberTest < ActiveRecord::TestCase
  context 'named scope active' do
    setup do
      @scoped_find = Member.active
    end

    should "have condition active" do
      expected_conditions  = {:conditions => ["member.status == #{Member::STATUS_ACTIVE}"]}
      assert_equal expected_conditions, @scoped_find.proxy_options
    end

    should "have results" do
      assert_not_nil(scoped.active.size)
    end
  end
end

The first test does part 1, the 2nd, part 2.

I had been getting this issue quite a bit recently. The cause actually turned out to be a conflict between McAfee and MySQL. What was happening is that McAfee scans any file that is recently written to, especially those in tmp directories. McAfee reading the file causes the above issue to MySQL. The fix is 2 fold. First, if you have not already, move the location of the MySQL tmp file. You can do this by editing my.ini in your MySQL directory. For Example:

tmpdir="C:/Program Files/MySQL/tmp/"


You may also have to add an exception to your antivirus so that it will no longer scan this file. I had to do this because I was using corporate antivirus. You may have to get your Sysadmin to do this.

Here is a post on mysql’s forums describing this issue as well

Object:

class User
  validates_presence_of :first_name, :last_name, :company_id
  belongs_to :company
  def full_name
    "#{last_name}, #{first_name}"
  end
  def company_name
    company.name
  end
end

Test:

class UserTest < Test::Unit
  def test_full_name
    assert_equal("Gaffney, Mike", User.new(:first_name => "Mike", :last_name => "Gaffney"))
  end
  def test_company_name
    company = Company.new(:name => "CompanyName")
    user = User.new(:company => company)
    assert_equal("CompanyName", user.company_name)
  end
end

This may seem like overkill but when many people are looking at the code it greatly helps communicate intention to others.

Testing:

I also found several methods to test protected and private methods in ruby, so I will cover the pluses and minuses the ones I know of.

Lets say we have a User class and an unassociated comments class. Comments are only attributed to a poster’s full name. There is no direct ID link between comments and users.

class User
  validates_presence_of :first_name, :last_name
  def find_comments
    Comments.find(:all, :conditions => {:poster => full_name})
  end
  protected
  def full_name
    "#{last_name}, #{first_name}"
  end
end

Here are the approaches I’m going to use to test this:

• Using a Mock to open access restrictions
• Make single (protected/private) methods public on the tested class.
• Make all (protected/private) methods public on the tested class.
• Hybrid Mock Approach
• Using instance_eval and send
• send

Using Mocks:
Mocks should be pretty familiar to most developers. Basically you create a class or subclass that the test will use. In our case we are simply opening the access restrictions with a subclass. Our test class looks like this:

class MockUser < User
  def full_name
    super
  end
end
class UserTest < Test::Unit
  def test_full_name
    user = User.new(:first_name => "Mike", :last_name => "Gaffney")
    assert_equal("Gaffney, Mike" user.full_name)
  end
end

Plusses:

• Simple and familiar to most developers from many languages

Minuses:

• Can’t test private methods (subclass doesn’t have access).
• With complicated classes you end up with quite a few mocks for all of the different cases. Managing the mocks becomes tedious.

Make single methods public:
Next we will make use of the runtime nature of ruby to change a function from protected to public. This also works for private methods:

class UserTest < Test::Unit
  def test_full_name
    User.send(:public, :first_name)
    user = User.new(:first_name => "Mike", :last_name => "Gaffney")
    assert_equal("Gaffney, Mike" user.full_name)
  end
end

or

class User
    public :first_name
end
class UserTest < Test::Unit
  def test_full_name
    user = User.new(:first_name => "Mike", :last_name => "Gaffney")
    assert_equal("Gaffney, Mike" user.full_name)
  end
end

Plusses:

• Lets us directly access the private or protected function.

Minuses:

• This pollutes the default namespace for all of the other tests. Remember that tests can (and should be able to) run in random order. Take for example:
  1. Full Name is a public function that some other objects use.
  2. We make this function into a protected one and use this method to make it public for testing.
  3. If this new test runs before the tests for the objects using the old public full_name, full_name will still be public even though it is actually protected.
  4. The other tests do not fail but the code will fail during runtime.

Make all methods public:
To save us some time on a big class, we can make all private and protected methods public:

class User
  public *protected_methods.collect(&:to_sym)
  public *private_methods.collect(&:to_sym)
end
class UserTest
  def test_full_name
    user = User.new(:first_name => "Mike", :last_name => "Gaffney")
    assert_equal("Gaffney, Mike" user.full_name)
  end
end

or

class UserTest < Test::Unit
  def test_full_name
    User.send(:public, *MyClass.protected_instance_methods)
    User.send(:public, *MyClass.private_instance_methods)
    user = User.new(:first_name => "Mike", :last_name => "Gaffney")
    assert_equal("Gaffney, Mike" user.full_name)
  end
end

This has the same issues as above but can be done one to make large classes easy to test, especially using the first method.

Hybrid Approach:
This works like the mock example and the previous example combined:

class AllAccessUser
  public *protected_methods.collect(&amp:to_sym)
end
class UserTest < Test::Unit
  def test_full_name
    user = AllAccessUser.new(:first_name => "Mike", :last_name => "Gaffney")
    assert_equal("Gaffney, Mike" user.full_name)
  end
end

This is easy like the previous but does not pollute the namespace. However it cannot be used for private methods.

Using send
Now we will use the built in reflection method to call the protected/private method on the class. This makes use of the fact that protected and private in ruby aren’t really like protected and private in other languages.

class UserTest < Test::Unit
  def test_full_name
    user = User.new(:first_name => "Mike", :last_name => "Gaffney")
    assert_equal("Gaffney, Mike" user.send(:full_name))
  end
end

Plusses:

• Doesn’t pollute the namespace.
• All code is right in the test.
• Works for protected and private.

Minuses:

• Some people don’t like using send

Summary:
Testing protected and private methods should be done, and ruby makes it much easier than some other languages. My preferred technique is the final one of using send. It is slightly less readable but keeps everything contained in one location.

User.new(:name => “tony”){|u| u.save}

which is great for active record tests.

Or in a bigger example:

@trip = Trip.new{|t| t.save!}
@invite1 = Invitation.new(:user => users(:aaron),
                                   :status => Invitation::STATUS_MAYBE){|i| i.save}
@invite1 = Invitation.new(:user => users(:aaron),
                                   :status => Invitation::STATUS_MAYBE){|i| i.save}