BEGIN:VCALENDAR PRODID;X-RICAL-TZSOURCE=TZINFO:-//Calagator//EN CALSCALE:GREGORIAN X-WR-CALNAME:Calagator METHOD:PUBLISH VERSION:2.0 BEGIN:VTIMEZONE TZID;X-RICAL-TZSOURCE=TZINFO:America/Los_Angeles BEGIN:STANDARD DTSTART:20151101T020000 RDATE:20151101T020000 TZOFFSETFROM:-0700 TZOFFSETTO:-0800 TZNAME:PST END:STANDARD END:VTIMEZONE BEGIN:VEVENT CREATED;VALUE=DATE-TIME:20151104T172208Z DTEND;TZID=America/Los_Angeles;VALUE=DATE-TIME:20151214T210000 DTSTART;TZID=America/Los_Angeles;VALUE=DATE-TIME:20151214T180000 DTSTAMP;VALUE=DATE-TIME:20151104T172208Z LAST-MODIFIED;VALUE=DATE-TIME:20151201T182518Z UID:http://calagator.org/events/1250469343 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 o f New Relic will discuss how to tackle the complex testing issues that c ome up when your code needs to be compatible with multiple dependencies. \;\n \;\nFor more information about this and future meetings\, fo llow @TestRubyPDX on Twitter. \;\n \;\n### Testing the Multiverse& #13\;\n#### Jason Clark \;\nIt’s a basic principle of testing that mi nimizing dependencies will make you happier\, faster\, and more producti ve. But what happens when you can’t? If your code plugs into or extends another gem\, comfortable isolation might be out of the question. Stubbi ng 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! \;\n \;\n### ActiveMocker: Fast ActiveRecord Mock s \;\n#### Dustin Zeisler \;\nTired of a slow test suite in Rails? Hitting the database so often it's getting you down? Is waiting for Rai ls 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 minu tes? You may say "\;That's all great\, but I'll have to change the w ay I test and program adding tedious boilerplate\, making my code ugly.& quot\; 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 settin g 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 model s 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\, al lowing you to stub it with a mocking framework\, like RSpec. Mocks are r egenerated when the schema is modified so your mocks won't go stale\, pr eventing the case where your units tests pass but production code fails. \;\n \;\n## Thanks to Renew Financial for providing the space and pizza for this event!\n\nTags: ruby\, rails\, testing\, agile\, Cucumbe r\, RSpec\, Test::Unit\, Minitest\, Capybara\, activerecord\, ActiveMock er\n\nImported from: http://calagator.org/events/1250469343 URL:http://testrubypdx.org SUMMARY:Test Ruby PDX Monthly Meeting LOCATION:Renew Financial: 402 SW 6th Ave. #902\, Portland OR 97202 US SEQUENCE:6 END:VEVENT END:VCALENDAR