If you want real end-to-end testing of a page with functioning AJAX, use Selenium. But I was interested in doing just a bit of JS speccing to make sure that the AJAX routes I called worked and that the data that came back fit the JS that I had written.
So, I figured with a little and a little , I could test my javascript with real route calls. Let’s check it out.
Read the rest of this entry »
Timecop 0.3.4 has just been released. To install simply run: gem install timecop.
Timecop is a RubyGem providing “time travel” and “time freezing” capabilities, making it dead simple to test time-dependent code. It provides a unified method to mock Time.now, Date.today, and DateTime.now in a single call.
Documentation is hosted at . The source code is hosted at .
Updates include:
Timecop 0.3.0 has just been released. To install simply run: gem install timecop.
Timecop is a RubyGem providing “time travel” and “time freezing” capabilities, making it dead simple to test time-dependent code. It provides a unified method to mock Time.now, Date.today, and DateTime.now in a single call.
Documentation is on . The source code is hosted at .
Updates include:
API
Maintenance
Documentation
has a great post to get you started with for Ruby on Rails.
I wanted to preview my HTML emails without having to fill up my online email inboxes with tons of email (and then I’d have to make filters too). I also didn’t want to manage actually sending real email. So, I set up my machine for local delivery. Read on for instructions.
Read the rest of this entry »
is a very handy tool to detect which SQL queries are running slowly in a production app.
So what about rails applications? Often, test data only contains a small amount of data. Over time more users use the site and generate more data. A page that usually renders in 100ms could be taking 3-5 seconds, or more!
I present, . The goal was to analyze a standard log file to detect actions that render slowly. It had to be easy to use and also not require modification of rails’ logging mechanism. Observe:
$> slow-actions --actions development.log
Cost Average Max
- UsersController : game_history (22 entries, 0% Error)
Total: 11275.447 3642.437 12728.0
Render: 7.20300 2.32700 17.2450
DB: 10.5020 3.39200 10.0000
- QuestionsController : refresh_index_table (89 entries, 0% Error)
Total: 908.494 202.348 307.000
Render: 0.00000 0.00000 0.00000
DB: 32.5880 7.25800 10.0000
More info after the break ….
Read the rest of this entry »
It’s very rare that I do any C++ programming these days. However, one of my oldest customers continues to utilize a C++-based optimization/statistics framework that we helped them build many years ago. The project has a , and we owe quite a bit to some of the first people to trust us (thank you Sommer and Dorry!).
As a Ruby programmer, I’ve come to love test-driven programming. As such, I’ve made an effort recently to build a test-based workflow into this existing codebase (not always the easiest thing to do, applying a test-base to a large existing codebase). Today I found myself in dire need of being able to test private functions in C++. As a testament to the poor state of testing in other programming languages, many message boards/threads simply told me that I was testing the wrong thing (you should test the public API, not the private implementation). Well, needless to say, this left me a bit uncomfortable. The fact is, the majority of my code is tucked into private methods, and I’d be left with huge long-running end-to-end tests if I strictly followed this heuristic.
However, I came across one golden nugget, one of the most clever hacks I’ve seen in some time. By utilizing pre-processor directives, we can temporarily override the meaning of private and protected in C++ code, essentially aliasing it to public.
#define protected public #define private public #include "TheClassHeaderUnderTest.h" #undef protected #undef private
See what this is doing? We wrap the class that we’ll be testing in pre-processor directives to interpret protected and private as an alias for public, essentially loading that class (when including the header file) as entirely public. This allows me to access everything! Private methods, private variables, you name it. And now, just like in Ruby, it’s no holds barred, allowing me to poke and prod my objects without being wrapped on the wrist by the compiler.
Even better, these directives simply wrap your includes in your test files. In other words, I don’t have to change my implementation to achieve this.
A clever hack, no matter the language or technology, is a clever hack. And I absolutely love this hack.
Credit: I discovered this technique as a comment on .
This one had me frustrated for the past hour. I’ve been writing integration tests for a Rails project and got stuck on an error when I was trying to test that a file upload worked successfully and asserted a redirection was occuring correctly, but ran into the following error:
Expected response to be a <:redirect>, but was <500> <"No HTTP_REFERER was set in the request to this action, so redirect_to :back could not be called successfully. If this is a test, make sure to specify request.env[\"HTTP_REFERER\"].">
What a lovely error message to send me on a goose chase trying to set HTTP_REFERER directly on the @request as instructed.
@request.env["HTTP_REFERER"] = '/' post upload_path, { :file => fixture_file_upload("worddoc.docx", "application/msword") }, { :html => {:multipart => true} } assert_redirected_to '/', 'index'
This continued to spit out the same error. I finally stumbled across that held the answer. The HTTP_REFERER is not set the same way in an integration test:
post upload_path, { :file => fixture_file_upload("worddoc.docx", "application/msword") }, { :html => {:multipart => true}, :referer => '/' } assert_redirected_to '/', 'index'
Hope that saves anyone else some time if you encounter this error.
I just released version 0.2.0 of this evening (morning).
The primary feature added was the distinction between “freezing” and “rebasing” time. In 0.1.0, Timecop.travel would actually freeze time. This is no longer the case. Rather, a time offset will be calculated, and a running clock is simulated by always offsetting the time returned by Time.now (and friends) by the original offset.
(Note that time can still be frozen with Timecop.freeze.)
This past weekend I released v0.1.0 of the gem. Timecop makes it dead simple to travel through or freeze time for the sake of creating a predictable and ultimately testable scenario.
The gem is derived from a plugin I wrote a while back to achieve more or less the same functionality for an extremely time-sensitive application. My goals for the gem included:
The gem is hosted on RubyForge and can be installed by simply running:
sudo gem install timecop
I’ve found myself on a benchmarking kick these last couple of weeks. Sometime last week, I dug up the library written by . Pistos’ library is basically just a wrapper for the , which is more or less an interface to (similar to what is to ).
Combining these tools together, we can do some pretty nifty code performance analysis in very few lines of code, e.g.
require 'rubygems' require 'better-benchmark' result = Benchmark.compare_realtime(:iterations => 10) { |iteration| save_the_world() }.with { |iteration| save_the_world_and_save_the_girl() } Benchmark.report_on result
I have and wrapped the library up into a .
You are currently browsing the archives for the Testing category.