Test Ruby PDX is a new user group focusing on testing from a developer's perspective. Join us for peer mentoring, conversation, and pizza at 6, followed by presentations at 7. This month, Jason Clark of New Relic will discuss how to tackle the complex testing issues that come up when your code needs to be compatible with multiple dependencies.

For more information about this and future meetings, follow @TestRubyPDX on Twitter.

Testing the Multiverse

Jason Clark

It’s a basic principle of testing that minimizing dependencies will make you happier, faster, and more productive. But what happens when you can’t? If your code plugs into or extends another gem, comfortable isolation might be out of the question. Stubbing and careful design can carry you a ways, but eventually you need to actually test your code against those gems you’re building on. Luckily, there are ways to reduce this pain. We’ll dig deep on creating a simple environment to check your work against multiple dependencies. We’ll see patterns that help avoid pulling your hair out when those dependencies change. We’ll even search around the raw edges, examining how to verify what your code does when it lands in an environment you haven’t tested. There’s a multitude of gems out there to build on. Let’s see how we can test with them!

ActiveMocker: Fast ActiveRecord Mocks

Dustin Zeisler

Tired of a slow test suite in Rails? Hitting the database so often it's getting you down? Is waiting for Rails to boot as you do red, green, refactor killing your vibe? Wouldn't it be great if your tests ran in milliseconds instead of seconds or minutes? You may say "That's all great, but I'll have to change the way I test and program adding tedious boilerplate, making my code ugly." And I would say, no! I created ActiveMocker to save my team from just that. You can have nearly all of the benefits by adding one setting to your test file and with just a little more work you can have full, glorious, unadulterated speed. ActiveMocker creates mock classes from ActiveRecord models, allowing your test suite to run at breakneck speed. This can be done by not loading Rails or hitting a database. The models are read dynamically and statically so that ActiveMocker can generate a Ruby file to require within a test. The mock file can be run by itself and comes with a partial implementation of ActiveRecord. Attributes and associations can be used the same as in ActiveRecord. Methods have the same argument signature but raise a NotImplementedError when called, allowing you to stub it with a mocking framework, like RSpec. Mocks are regenerated when the schema is modified so your mocks won't go stale, preventing the case where your units tests pass but production code fails.

Thanks to Renew Financial for providing the space and pizza for this event!

Conversation and peer mentoring starting at 6, presentations at 7. For more information, follow @TestRubyPDX on Twitter or join the #testrubypdx Slack channel (under PDX.rb).

Presentations

Bernerd Schaefer: Refactor Your Feature Specs!

expect(page).to have_css(".active"). It's clear what this line does, but what is it really testing? And why? Together we'll take some real-life feature specs and refactor them so the intent of the spec shines through.

Portland's testing user group for Ruby developers! Conversation and peer mentoring starting at 6, presentations at 7. For more information, follow @TestRubyPDX on Twitter or join the #testrubypdx Slack channel (under the pdxruby team).

How and Why to Test Rake Tasks - Brett Chalupa

Testing classes and modules is essential to writing well tested Ruby code. However, testing Rake tasks is not as straight-forward. In this talk, you will learn how and why it is valuable to test Rake tasks. This talk will go over testing regular ole Rake tasks and Rake tasks in a Rails app. Before you know it, you will be writing Rake tasks in a test-driven manner, hooray!

Portland's testing user group for Ruby developers! Conversation and peer mentoring starting at 6, presentations at 7. For more information, follow @TestRubyPDX on Twitter or join the #testrubypdx Slack channel (under the pdxruby team).

Paul Baker - Golden Thorns: Lessons from the Gilded Rose Kata

The Gilded Rose Kata is a fairly well known kata that utilizes a "golden master testing" strategy to provide safety while the developer refactors a messy legacy code base in order to add new features. I will walk through my take on the kata and then review some lessons that I have learned as a sr. developer working with legacy code and where this pattern can be helpful.

Portland's testing user group for Ruby developers! Conversation and peer mentoring starting at 6, presentations at 7. For more information, follow @TestRubyPDX on Twitter or join the #TestRubyPDX Slack channel (under the pdxruby team). We are still looking for speakers, so if you're interested, visit testrubypdx.org/speak for details and suggested topics!

Portland's testing user group for Ruby developers! Conversation and peer mentoring starting at 6, presentations at 7. For more information, follow @TestRubyPDX on Twitter or join the #testrubypdx Slack channel (under the pdxruby team). We are still looking for speakers, so if you're interested, visit testrubypdx.org/speak for details and suggested topics!

Test Ruby PDX is a user group focused on Ruby testing. In particular, we are developers interested in testing our own code. We offer pizza, conversation, and peer mentoring starting at 6 before moving on to presentations at 7. This month, Daniel Dreier of Puppet will talk to us about how to test command line apps using Cucumber and Aruba.