Dave Schweisguth in a Bottle

How many meanings of that can you think of?

Archive for the ‘Testing’ Category

Using and testing automatic accessors and virtual attributes of ActiveRecord models

leave a comment »

An ordinary ActiveRecord model object has an attribute for each column in its table. Each attribute has a reader method and a writer method. However, ActiveRecord also defines accessors on the fly to hold non-column query results. Also, sometimes it’s useful to define a new attribute, one not corresponding to a column or even to a field in a query result. These different kinds of extra attributes can interfere with one another, making them tricky to use and test. The best defense is to understand all of them well before using any of them. Let’s have a look.

Read the rest of this entry »

Written by dschweisguth

August 11, 2016 at 09:44

Posted in Programming, Rails, Ruby, Testing

Controlling database usage in RSpec and factory_girl, part 2: association strategy and unstubbed queries

leave a comment »

An important part of testing a Rails application is establishing the correct relationship between the specs of each layer and the database. To correctly test the layer that they test, some types of specs (model and feature specs) should run against the database; other types should not. As well as ensuring correctness, policing database usage optimizes performance: tests that use the database are slower.

This post, part 2 in a two-part series, describes two measures that you can take to minimize incorrect and unnecessary database usage in RSpec specs that use factory_girl.

Read the rest of this entry »

Written by dschweisguth

June 21, 2014 at 15:45

Posted in Programming, Rails, Ruby, Testing

Controlling database usage in RSpec and factory_girl, part 1: Choosing and allowing appropriate strategies

leave a comment »

When testing each layer of a Rails application, it’s important to create test model instances in the right way for that layer. Some specs need model instances that have been saved in the database, or that appear to have been; others need instances that have not. It’s also important to not use the database when you don’t have to, because every use makes your tests take a little bit longer.

This post, part 1 in a two-part series, lays out the appropriate use of factory_girl in specs of each layer of Rails, and gives a way to enforce that usage.

Read the rest of this entry »

Written by dschweisguth

June 21, 2014 at 12:27

Posted in Programming, Rails, Ruby, Testing

Dark corners of unit-testing lore

leave a comment »

The software community’s understanding of developer testing (unit testing, acceptance testing, etc.) has come a long way since “Extreme Programming Explained” and “Refactoring” and JUnit got everyone interested almost fifteen years ago. There was a time when developers argued whether unit testing was valuable (never mind TDD); now it’s taught in code camps as an essential skill.

But some testing techniques have remained out of the mainstream, for whatever reason. A couple of them came up on Stack Overflow recently and I was inspired to give long answers. Whether or not these techniques eventually become part of standard practice, they’re interesting to know about and possibly useful in shaping your thinking about mainstream practices.

Read the rest of this entry »

Written by dschweisguth

June 3, 2014 at 14:13

Posted in Java, Programming, Testing

How I spent my working vacation

leave a comment »

While at Fandor (still the finest independent and international film streaming service) I had almost no time for personal projects, but I did manage to write a few blog posts on Fandor’s late engineering blog, “Behind the Fan Door” (as my Fandor doppelgänger, fandave). These fit the best with my own interests and the rest of this blog:

Also, the idea of data testing is interesting, although its context in that post is less so. And, for completeness, here’s every single one.

[2017 update: “Behind the Fan Door” is gone, so I’ve replaced links to it with links to archived copies on my own site. Links in the copies are, unfortunately, mostly broken.]

Written by dschweisguth

March 2, 2014 at 08:31

Posted in Programming, Testing

Succinct specs for Rails named routes

leave a comment »

I like all of my routes tested, and I like all of my routes named, and I like all of my named routes tested. I even like to test my RESTful routes; even though it feels a bit like testing Rails, it more than paid for itself when migrating to Rails 3. How, then, to spec a named route succinctly?

Read the rest of this entry »

Written by dschweisguth

May 11, 2011 at 08:48

Posted in Programming, Rails, Ruby, Testing

Rails’ named routes considered helpful

leave a comment »

The current Rails best practice is to use RESTful routes. One nice thing about a RESTful route is that it comes with a name. Similarly, :member and :collection routes are automatically named. But sometimes you need a plain old arbitrary route, which you can then name or not as you wish. It may seem like overkill to give every route a name, especially if the route is referred to infrequently in templates. But there’s another place where you’re virtually guaranteed to need that named route again: in tests.

Read the rest of this entry »

Written by dschweisguth

May 11, 2011 at 08:36

Posted in Programming, Rails, Ruby, Testing

Do dynamic languages need more tests than static languages?

leave a comment »

Recently I made an error in a Ruby program (a Rails application) that I wouldn’t have been able to make in a Java program. I renamed a model method manually — because another class had a method with the same name, and RubyMine’s Rename Method refactoring would have renamed both methods — and although I renamed the method itself and uses of the method in the model object’s spec, I missed uses of the method in a controller and mocks of it in the controller’s spec. All of the tests passed, but the application broke. “Gee,” I thought, “if I’d had to compile everything first, that couldn’t have happened.”

Read the rest of this entry »

Written by dschweisguth

May 2, 2011 at 18:09

Posted in Programming, Testing

Upgrading GWW from Rails 2, RSpec 1 and prototype to Rails 3, RSpec 2 and jQuery

leave a comment »

GWW originated on Rails 1; I upgraded it to Rails 2 last year. I’d been putting off the upgrade to Rails 3 until a bug in Phusion Passenger which breaks redirects in Apache httpd was fixed, but I want to use a database adapter which supports MySQL spatial features, and that requires Rails 3. I said goodbye to page caching until (crossing fingers) Passenger 3.0.6, made a branch and started editing my Gemfile.

Although Rails 3 has been released for more than half a year, upgrading involved many hiccups and a couple of landslides. I’d have been happy to just update my gems and be done with it, but I had to hunt around enough that it seemed worth logging what I did in case it helped someone else. I’ve kept it as short and to-the-point as I could. Although I fixed all of the deprecations that Rails 3 reported as I encountered them, I won’t mention them further, since in every case they were completely clear and fixing them only required following instructions. I’ve also left out a handful of odd little incorrectnesses in GWW which worked in Rails 2 but broke in Rails 3, since the details probably won’t interest anyone else and the fixes were obvious. Otherwise, here’s how the upgrade went.

Read the rest of this entry »

Written by dschweisguth

April 4, 2011 at 08:29

Posted in Programming, Rails, Ruby, Testing

Homebrewed ActiveRecord test object factories for rspec

leave a comment »

I recently took GWW from a handful of Test::Unit tests to 100% test coverage. It took some good tools (rspec and RR (Double Ruby) are both terrific), but what I didn’t do was use either of the widely used test object factory libraries, factory_girl or Machinist. I wasn’t going to use Rails fixtures, either — fixtures are just wrong — but the factory libraries rubbed me the wrong way. I could point to bits of each tool that weren’t exactly what I wanted, but the real reason I didn’t use either one was that they both seemed a little much when all I wanted to do was construct a few objects. Yes, I recognized the sound of a wheel about to be reinvented, but I went ahead anyway, and I ended up with a small amount of code very well tuned to my needs, and a couple of nice features that I don’t think the off-the-shelf solutions provide.

Read the rest of this entry »

Written by dschweisguth

March 2, 2011 at 10:01

Posted in Programming, Rails, Ruby, Testing