Testing on Jake Worth

Writing the DOM with fs

Fri, 30 Jan 2026 11:12:52 -0500

How can I output the entire DOM to a file in a JavaScript test?

Custom Ipsum for Real-World Testing

Fri, 27 Jun 2025 16:00:28 -0400

Pastures which are subject to overflow should be avoided. All lambs born in April or May should be drenched about August or September following, to be certain of ridding them of worms that may later cause their death.

This is output from a tool I built called Veterinary Ipsum. It’s something I’ve created a few times: a Lorem Ipsum generator specific to my company’s business domain.

Thinking of Bugs in Classes

Sun, 03 Sep 2023 00:00:00 +0000

We spent the time writing tests, and yet, a bug survived. Should we just stop writing tests? No, but we should maybe write better tests, and think about them differently.

Cold Water for Your Code Coverage

Tue, 28 Mar 2023 00:00:00 +0000

Code coverage, the percentage of your code covered by automated tests, is a metric associated with quality. In this post, I’d like to investigate this association. And pour some cold water on it.

The Factory Pattern, Explained in Ruby

Mon, 17 Oct 2022 00:00:00 +0000

In this post, I’ll explain what factories are and why you want them, using Ruby.

RSpec.describe vs. describe: Which Should I Use?

Sat, 02 Apr 2022 00:00:00 +0000

Ruby’s RSpec describe block has two common syntaxes. Which should you use?

On Disabling Tests

Tue, 22 Feb 2022 00:00:00 +0000

Today I want to talk about a common technique: disabling failing tests to allow a feature to ship. Maybe sometimes you gotta do it. But long-term I think it causes more problems than it solves.

Want Better Automated Tests? Hard-Code Your Expectations

Tue, 25 Jan 2022 00:00:00 +0000

Hard-coded test expectations have many benefits that I’ll explore in this post.

ExtractRSpecLet

Wed, 21 Apr 2021 11:13:08 -0400

Today I got to see the :ExtractRspecLet command from the vim-weefactor plugin. It does what the names suggests, converting this:

# spec/model/foobar_spec.rb

foo = FactoryGirl.create :foobar

To this:

# spec/model/foobar_spec.rb

let(:foo) { FactoryGirl.create :foobar }

It also moved the new let from inside my it block to right underneath my context block. Awesome!

h/t Josh Davey and Dillon Hafer

A Short Introduction to Test-Driven-Development (TDD)

Wed, 11 Sep 2019 00:00:00 +0000

I’ve practiced TDD (Test-Driven-Development) a lot and feel knowledgable about when it’s useful and when it isn’t. In this post, I’d like to summarize what I’ve learned.

Learn to Test

Fri, 15 Jul 2016 00:00:00 +0000

What is a skill one could learn to set themselves apart from other entry-level programmers? Testing.

Expect a Case-Insensitive Match

Tue, 05 Jan 2016 17:37:00 -0600

We had a testing issue this week when a button’s text save changes! was rendering as SAVE CHANGES!, due to the CSS property text-transform: uppercase. How do you test that?

One technique is to use RSpec’s match method, and include case insensitivity with i (explored earlier here):

> button_text = "foo"
=> "foo"
> expect(button_text).to match("FOO")
RSpec::Expectations::ExpectationNotMetError: expected "foo" to match "FOO"
# stuff
> expect(button_text).to match(/FOO/i)
=> true

We ultimately hard coded the expectation to match("FOO"), because allowing fOo and FoO seemed too permissive. But it remains an option.

Testing Edit Forms

Tue, 17 Nov 2015 07:53:31 -0600

Today I found a way to assert that an edit form’s inputs include a record’s saved data. I think it strikes a good balance between broad and narrow scope.

# spec/features/user_edits_kit_spec.rb

within 'form' do
 expect(page).to have_selector("input[value='Default copy.']")
end

This asserts that some content is inside an input field in the form, rather than just anywhere on the page. You can narrow the scope as needed.