Erics Tech Blog » testing

Should I Mock Kernel#exit

eric — Mon, 26 Apr 2010 09:00:44 +0000

I don’t know what the right answer is, so any insight would be appreciated. From Googling around, I came across this thread on StackOverflow which talks about Validating exits and aborts in Rspec. I have a few issues with this, namely that I am using shoulda and I don’t want to validate the exit, I want to stop it from happening inside of the test.

I have figured out that rescueing a Kernel#exit with afford the same opportunity to test results so I am not sure if mocking it is necessary. Consider the following code which doesn’t involve mocking:

class Application
def thread_cleanup(threads)
threads.each do |thread|
thread.kill
end
$stderr.puts "Terminating..."
exit
end
end

# test cases
class ApplicationTest < Test::Unit::TestCase
should "kill all threads and exit cleanly" do
threads = Array.new
threads.push(Thread.new { sleep }, Thread.new { sleep })
begin
Application.thread_cleanup(threads)
rescue SystemExit => e
assert_equal 0, e.status
end
end
end

Here we rescue the exit and continue on with the testing. The tests don’t actually exit (which allows the suite to continue) and no mocking of core functionality is required. Is it the better way? I don’t know, but it works.

Multiple Input Locations From Bash Into Ruby

Peertester Community Testing

eric — Tue, 16 Mar 2010 11:00:02 +0000

I am all about community and people participating in a community. Its the way social media succeeds. But there are non-social media communities out there too (yes I know that’s shocking). I was recently asked to participate in a beta testing for Peer Tester. I think this is an absolutely fantastic idea. Developers helping other developers test their apps. Hats off to the guys and gals over at Engine Yard for designing and putting this application together. Other than the fact that I got tired of looking at that olive green color after years in the military, this site is an great tool for developers.

So now you’re probably asking what exactly it is. Well, you create an account and then create tests for your web application. The tester will then follow your instructions, clicking on what you tell them to do or reading what you tell them to read. Then they are asked questions (multiple choice, short answer, or whatever suits the situation) while they are going through the testing. You can then view their feedback and modify (or not modify) your application accordingly.

For people like me who absolutely suck at flow and visual aesthetics, this is great to see if others think your product elicits the expected reaction. You can even specify the number of people you want to use as a sample size for testing. But just like with any good community site, you need to participate in order to have the site excel. You gain points and get badges for participation and bug finding.

Remember, the site is still in beta (and I can only hope that it will change the site color before it gets out of beta, but that’s me) so there may be some bugs. I encourage everyone to take a look. A little extra application testing never hurt anyone.

Testing Sessions with Digest::SHA256 Passwords In Rails

eric — Fri, 17 Jul 2009 06:00:31 +0000

I am fairly new to Rails, but from what I have learned thus far, its fantastic. I plan on posting more obscure Rails items as I come across them.

I am writing an application that is similar in functionality to Yelp (in some ways). I have had some help along the way from a seasoned Rails vet. One of the things he helped me with was setting up the sessions_controller. He did this in such a way that I wasn’t initially sure how to write the functional tests for it. The sessions_controller contained code like this (it’s a bit more in depth than this, but this will give you the idea):

def create
@current_user = User.find_by_username( params[:username] )
if @current_user.nil? or Digest::SHA256.hexdigest( params[:password] + @current_user.password ) != @current_user.password_salt
redirect_to( login_path )
else
redirect_to( user_path )
end
end

So when it came time to write the functional tests for this (using fixtures), I couldn’t get away with just a user.yml like this:

test_user:
username: test_user
password: secretuser
firstname: General
lastname: User
email: test_user@user.com
role: normal
nickname: Mr. Testy

The reason for this is because the user table contains an extra column pertaining to the password called password_salt (which you’ll notice referenced above). Therefore my user fixture needed to look something more like this:

test_user:
username: test_user
password: A0Mrhnu4 # secretsalt
password_salt: 868532ea243f03c2ce5f6f99dcf9e27342c39ce51819fa0605302ab4b5c3841e
firstname: Test
lastname: User
email: test_user@example.com
role: normal
nickname: Mr. Testy

The other fixture still has it usefulness in testing (like testing logins that won’t work), so don’t get rid of it so quickly.

How do I generate that salt and the hashed password? I’m glad you asked. I’m sure there is a better way to do it than I did, but I just went into the application, created a user and then went into the console, grabbed the user information and copied it into the fixture. Then I used the following code in my sessions_controller_test.rb for the functional test:

def test_should_logout_and_clear_session
post :destroy, :username => 'test_salt', :password => 'secretsalt',
:return_to => '/'
assert_redirected_to '/'
end