Test Ruby PDX Monthly Meeting
Access Notes
Renew Financial has offices on the 8th and 9th floors of the same building. Be sure to check the listing to know which one you're going to as access is limited after hours.
The meeting will be held on the 1st floor of the building. Use the doors on the left. Attendees should give the name of the event “Test Ruby PDX” to the security officer when they press the button to be allowed access into the building. The conference room is right across from that entrance on the first floor.
Website
Description
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.
rails
ruby