Archive for the ‘RSpec’ Category

JRuby & JTestR in Eclipse

Continuing my rampage upon the JRuby community, I have achieved beautiful success with running my tests inside of the eclipse IDE as a JUnit test. Now I have limited knowledge in the JUnit realm and encourage those to improve upon my approach.

In your eclipse Package Manager sidebar, Right Click -#> Run As.. -#> Run Configurations. Go ahead and select ‘JUnit’ and hit the ‘New Launch Configuration’ button.

Fill in the configuration as follows:

* Run a single test
Project: your-project-name
Test class: org.jtestr.ant.JtestRSuite

Now just open the ‘Arguments’ tab and inside the ‘VM arguments:’ box

-Djtestr.junit.tests=rspec_tests

rspec_tests is the folder where my tests are stored, feel free to change this to something like /test/jtestr/funny_test or whatever structure you store your files in.

I am still trying to figure out a more effecient way to get these test to run under eclipse. Till than I can always fall back on this approach as well as the standard ant task.

Tags: ant, JRuby, JtestR, junit, jvm, RSpec
Posted in Development, JRuby, RSpec | Comments (1)

JtestR - alive and kicking

Last week I posted about my JtestR problems and the lack of any solution. Well after some generous help from Ola Bini, JtestR’s lead developer, we found the problem. Apparently, you cannot run your Java application with the jtestr.jar file inside the root directory. The jar must be placed within a subdirectory, otherwise your Ruby runtime will try to include the JtestR.jar file through its require ‘jtestr’ statement. Its an odd quirk, with an easy workaround. Ola Bini has said its fixed in the latest trunk build, but to use the workaround until 0.4 comes out. I would like to thank him for all his help troubleshooting this issue. Cheers!

Tags: JRuby, JtestR, junit, jvm, RSpec, Ruby
Posted in JRuby, RSpec | Comments (0)

JtestR woes.

At work, all of our test and behavior driven development is done through the Fit libraries and an application layer called FitNesse. Now these are two tools that really fill a much needed void in the Java development world, however being an avid Ruby supporter I know that is far from the best. I decided to try RSpec and see if it had the chops to replace the dated and lacking Fit library.

It took about a day’s worth of google searching to find the best plan of action. Originally, I wanted to wire up JRuby and RSpec myself, but it seemed to involve too many hoops to be a viable option. Then I ran into JtestR thinking that it would be the end-all solution to my Java testing troubles. I was wrong.

The two days spent trying to get JRuby and JtestR to play nice with my Java project has culminated into an amazingly cryptic stack trace:

[junit] Exception in thread "main" java.lang.RuntimeException: Exception while running
    [junit]     at org.jtestr.JtestRRunner.execute(JtestRRunner.java:97)
    [junit]     at org.jtestr.ant.JtestRSuite.run(JtestRSuite.java:376)
    [junit]     at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRunner.java:289)
    [junit]     at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.launch(JUnitTestRunner.java:656)
    [junit]     at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main(JUnitTestRunner.java:558)
    [junit] Caused by: org.jruby.exceptions.RaiseException
    [junit] Test org.jtestr.ant.JtestRSuite FAILED

Now begins the adventure of asking JtestR’s lead developer, Ola Bini, for help. It seems he is not entirely sure why this problem is occurring which is not very comforting, when I am pitching RSpec as a test replacement for Fitness in a few weeks. I will keep you posted with updates, feel free to follow the mailing list.

Tags: debug, Fit, Fitnesse, Java, JRuby, JtestR, RSpec, stack trace
Posted in JRuby, RSpec | Comments (3)

RSpec puts my mind at ease.

Green never looked so good. Now that I am finally getting used to all the new RSpec syntax changes and settled into the 100% coverage realm, it is time to refactor some of my tests using some lambda tricks I have seen around the net.

Posted in RSpec | Comments (0)

RSpec - Mocks and Stubs

Behavior Driven Development (BDD) has become a driving force in the development industry right along the process of agile development. The two are almost synonymous with each other if you have done any sort of Agile/XP/SCRUM process on any of your projects. In the ruby world and the surrounding communities, RSpec has evolved as the leader for applying BDD practices and I felt it was about time I mastered the BDD process for all my projects.

The beauty of RSpec is in its simplicity. The code is very readable by anyone who comes across of it. For me, the syntax was the easy part. The headaches began once I tried to wrap my head around mocks (mocking) and stubs. Stubs seemed easier to start with, so I hit Google confident that my answer was just clicks away.

Well, I was wrong… After spending about an hour researching stubs, I figured maybe I should look up mocks. Unfortunately though, I got the same result posted at over 20 blogs. It was a link to a site called mockobjects. Now I am sure that somewhere on that site I could piece together an understanding of mocks and stubs, but I already had wasted a couple hours and did not have a day to spend on picking up these, seemingly simple, concepts.

Finally a ray of hope came when someone over at RailsForum posted the question I had been asking. The answers, although similar to ones I had read, made it clear as mud enough for me to take a stab at trying out some code. This is what I ended up with:

require File.expand_path(File.dirname(__FILE__) + '/../spec_helper')

describe UsersController, 'working with the show action' do

before(:each) do
@user = mock_model(User)
User.stub!(:find).and_return(@user)
end

it "should call the action successfully" do
get :show, :id => "1"
response.should be_success
end

it "should find the user" do
User.should_receive(:find).with("1").and_return(@user)
get :show, :id => "1"
end

it "should assign the found user to the view" do
get :show, :id => "1"
assigns[:user].should eql(@user)
end

end

describe UsersController, 'working with the index action' do
before(:each) do
@user = mock_model(User)
@users = [@user]
User.stub!(:find).and_return(@users)
end

it "should call the action successfully" do
get :index
response.should be_success
end

it 'should find the users' do
User.should_receive(:all).and_return(@user)
get :index
end

it 'should assign the found users to the view' do
get :index
assigns[:users].should eql(@users)
end
end

describe UsersController, 'working with the new action' do

end

describe UsersController, 'working with the create action' do

end

describe UsersController, 'working with the destroy action' do
before(:each) do
@user = mock_model(User)
User.stub!(:find).and_return(@user)
@user.stub!(:destroy).and_return(true)
end

it 'should find the user' do
User.should_receive(:find).with('1').and_return(@user)
delete :destroy, :id => 1
end

it 'should destroy the user' do
@user.should_receive(:destroy).once
delete :destroy, :id => 1
end

it 'should redirect to index' do
delete :destroy, :id => 1
response.should redirect_to(users_path)
end
end

Now I know I should have started with snippet by snippet and build up to a big post. However I feel its much easier to post the end result then break it down as we go, and its much quicker

Stubs: Simply put, it allows you to build canned responses to method calls. The reason for doing this is to maintain fast test execution by removing any database calls. Another factor is your controller tests (also known as functional tests) don’t need to rely on your models. Now when something breaks you don’t need to troubleshoot where to look since the model and controller are tested separately.

Mocks: Unlike stubs, I think of mocks as a basic barebone instance of an object. If you were to just define

@user = mock(’User’)

The @user object would respond to anything defined in your model. This means there is coupling between controller and model, unlike stubs, meaning when your tests break you need to do slightly more debugging. The amount of debugging can be minimized through good design.

To be continued.

Posted in RSpec | Comments (0)

© 2008 Justin Smestad & Evalcode.com. All Rights Reserved. | Design by DemusDesign. Powered by WordPress
The views expressed on this site are solely mine and not those of my employer.