"I love David Chelimsky"

2022-10-22 20:56:02

David Chelimsky random thoughtlessness RSS Blog Archives Slides Myron Marston and Andy Lindeman are RSpec’s new project leads Nov 28th, 2012 | Comments TL;DRMyron Marston is taking over leadership of the RSpec project, and willbe the lead maintainer of the rspec-core, rspec-expectations, andrspec-mocks gems.Andy Lindeman is taking over as lead maintainer of the rspec-rails gem.Myron Marston is RSpec’s new project leadMyron Marston has been contributing to RSpec since the ramp up to the2.0 release in 2010, and joined the core team in early 2011. In additionto solid contributions to the code base, Myron has taken responsibilityfor many bug reports, feature requests, pull requests, etc. He alsomakes a habit of answering RSpec-related questions on Stack Overflow andTwitter, and he does this all with thoughtfulness, patience, andwisdom.I can’t think of a better choice to lead the RSpec project, so I invitedhim to do so. Thankfully, SEOmoz, Myron’semployer, is allowing him to work on RSpec during work hours, and so heaccepted.In addition to the overall project lead, Myron will be the leadmaintainer of the rspec-core, rspec-expectations, and rspec-mocksgems. While Myron uses these core rspec libs every day for his work,he doesn’t do much with Rails, so we discussed and agreed that we’d asksomebody else to take care of the rspec-rails gem. Enter Andy Lindeman.Andy Lindeman is the new lead maintainer of rspec-railsAndy Lindeman is the newest addition to the rspec core team. Like Myron,Andy takes great care in shepherding pull requests and answeringquestions in addition to making his own rock solid contributions. Andyalso writes Rails apps and does Rails training atBig Nerd Ranch, which puts him in a greatposition to ensure that rspec-rails keeps up with changes in Railsremains a great choice for developing Rails apps.Thanks in part to Big Nerd Ranch for theirsupport of Andy’s work on RSpec, Andy has agreed to take the lead onrspec-rails.As for me …When Dave Astels introduced Steven Baker’s new RSpec library to me backin 2005, I started submitting patches, Steven gave me commit rights and,a year later, he decided to move on to other work and offered meleadership of the project. I was overjoyed to accept.In those days, I was teaching TDD/Refactoring courses for ObjectMentor. I was encouraged to work on OSS in my bench time, and I wasparticularly interested in tools that helped to promote thedocumentation and design aspects of TDD. RSpec and some of the earlydefinitions/discussions of BDD (“it’s all behavior!”) fit perfectly intomy thinking and my world.After I left Object Mentor, RSpec was part of my day to day work on Rubyapplications, but most of my work on its maintenance moved to my sparetime. This was fine at first, as I had the support of employers andfamily, but I found myself doing less and less of pretty much everythingelse that I enjoy and learn from.Back in June, I joined a project team at DRW Trading that deals in a lotof Clojure and almost no Ruby. In the roughly 6 months since, I’ve beenlearning a new domain, a new language, new programming models, and evena new text editor. I consider myself extraordinarily fortunate to beable to learn all of these new things, but I’ve found myself less andless able to balance my work on RSpec with my job and with everythingelse I want to do.And so, it is time.Of course, I’ll continue to contribute to the project and surroundingconversation, and I look forward to seeing all my friends in thecommunity at assorted conferences in the coming year(s). I’ll justbe arriving without my RSpec Lead hat on.Thank you to Steven Baker for handing me the wheel, and thank you toeverybody who has participated in the project and all RSpec users foryour support over these 6+ years. It’s been a great honor and a greatpleasure. rspec-2.12 is released Nov 12th, 2012 | Comments rspec-2.12 is a minor release (per SemVer), whichincludes numerous enhancements and bug fixes. It is fully backward compatiblewith previous rspec-2 releases and is a recommended upgrade for all users.Thanks to all who contributed. Special thanks to Myron Marston and AndyLindeman for their personal contributions to the code as well as a great jobshepherding pull requests from several new contributors.UPDATE: If you’re an rspec/rails/capybara user, be sure to read Andy Lindeman’s blog post on Capybara-2.0 and rspec-rails.DocsRDochttp://rubydoc.info/gems/rspec-corehttp://rubydoc.info/gems/rspec-expectationshttp://rubydoc.info/gems/rspec-mockshttp://rubydoc.info/gems/rspec-railsCucumber featureshttp://relishapp.com/rspec/rspec-corehttp://relishapp.com/rspec/rspec-expectationshttp://relishapp.com/rspec/rspec-mockshttp://relishapp.com/rspec/rspec-railsRelease notesrspec-core-2.12.0full changelogEnhancementsAdd support for custom ordering strategies for groups and examples.(Myron Marston)JSON Formatter (Alex Chaffee)Refactor rake task internals (Sam Phippen)Refactor HtmlFormatter (Pete Hodgson)Autotest supports a path to Ruby that contains spaces (dsisnero)Provide a helpful warning when a shared example group is redefined.(Mark Burns).--default_path can be specified as --default-path. --line_number can bespecified as --line-number. Hyphens are more idiomatic command line argumentseparators (Sam Phippen).A more useful error message is shown when an invalid command line option isused (Jordi Polo).Add format_docstrings { |str| } config option. It can be used toapply formatting rules to example group and example docstrings.(Alex Tan)Add support for an .rspec-local options file. This is intended toallow individual developers to set options in a git-ignored file thatoverride the common project options in .rspec. (Sam Phippen)Support for mocha 0.13.0. (Andy Lindeman)Bug fixesRemove override of ExampleGroup#ancestors. This is a core ruby method thatRSpec shouldn’t override. Instead, define ExampleGroup#parent_groups. (MyronMarston)Limit monkey patching of shared example/context declaration methods(shared_examples_for, etc.) to just the objects that need it rather thanevery object in the system (Myron Marston).Fix Metadata#fetch to support computed values (Sam Goldman).Named subject can now be referred to from within subject block in a nestedgroup (tomykaira).Fix fail_fast so that it properly exits when an error occurs in abefore(:all) hook (Bradley Schaefer).Make the order spec files are loaded consistent, regardless of theorder of the files returned by the OS or the order passed atthe command line (Jo Liss and Sam Phippen).Ensure instance variables from before(:all) are always exposedfrom after(:all), even if an error occurs in before(:all)(Sam Phippen).rspec --init no longer generates an incorrect warning about --configurebeing deprecated (Sam Phippen).Fix pluralization of 1 seconds (Odin Dutton)Fix ANSICON url (Jarmo Pertman)Use dup of Time so reporting isn’t clobbered by examples that modify Timewithout properly restoring it. (David Chelimsky)Deprecationsshare_as is no longer needed. shared_context and/orRSpec::SharedContext provide better mechanisms (Sam Phippen).Deprecate RSpec.configuration with a block (use RSpec.configure).rspec-expectations-2.12.0full changelogEnhancementsColorize diffs if the --color option is configured. (Alex Coplan)Include backtraces in unexpected errors handled by raise_errormatcher (Myron Marston)Print a warning when users accidentally pass a non-string argumentas an expectation message (Sam Phippen)=~ and match_array matchers output a more useful error message whenthe actual value is not an array (or an object that responds to #to_ary)(Sam Phippen)Bug fixesFix include matcher so that expect({}).to include(:a => nil)fails as it should (Sam Phippen).Fix be_an_instance_of matcher so that Class#to_s is used in thedescription rather than Class#inspect, since some classes (likeActiveRecord::Base) define a long, verbose #inspect.(Tom Stuart)rspec-mocks-2.12.0full changelogEnhancementsand_raise can accept an exception class and message, more closelymatching Kernel#raise (e.g., foo.stub(:bar).and_raise(RuntimeError, "message"))(Bas Vodde)Add and_call_original, which will delegate the message to theoriginal method (Myron Marston).Deprecations:Add deprecation warning when using and_return with should_not_receive(Neha Kumari)rspec-rails-2.12.0full changelogEnhancementsSupport validation contexts when using #errors_on (Woody Peterson)Include RequestExampleGroup in groups in spec/apiBug fixesAdd should and should_not to CollectionProxy (Rails 3.1+) andAssociationProxy (Rails 3.0). (Myron Marston)controller.controller_path is set correctly for view specs in Rails 3.1+.(Andy Lindeman)Generated specs support module namespacing (e.g., in a Rails engine).(Andy Lindeman)render properly infers the view to be rendered in Rails 3.0 and 3.1(John Firebaugh)AutoTest mappings involving config/ work correctly (Brent J. Nordquist)Failures message for be_new_record are more useful (Andy Lindeman) Agile Testing and BDD eXchange 2012 in NYC Sep 22nd, 2012 | Comments I’m excited to be presenting on Behavior-Driven Objects at the Agile Testing & BDD eXchange in NYC on Monday, October 1st (details below). From the conference website:One of the original ideas behind BDD was that testing should be about behavior at all levels. Effectively, all automated tests can be viewed as “functional tests” of entry points, be they user facing or internal, crossing procedural boundaries or not. In this talk we’ll explore approaches to focusing on the behavior of objects, using language that also serves to document the expected behavior in ways useful to both technical and non-technical stakeholders.The Agile Testing & BDD eXchange is a one-day conference with talks, open-space discussions and focus on ‘quality time’ between presenters and attendees. There is a nice blend of technical talks like Uncle Bob Martin talking about how to apply SOLID principles to test design, and more process oriented talks like Ellen Gottesdiener’s talk on product definition through structured conversation.You can read the full program and purchase tickets at http://bit.ly/S0Ypb8 (be sure to use the promo-code “bddxnyc-community-discount”).What: Agile Testing & BDD eXchange NYCWhen: October 1st 2012Where: The Ace Hotel NYCTwitter: #BDDXNYC rspec-2.11 is released! Jul 7th, 2012 | Comments rspec-2.11.0 is out and filled with a bunch of new features. Big thanks to allwho contributed, especially Justin Ko, AndyLindeman (the newest addition to the RSpec coreteam) and Myron Marston for their great jobaddressing issues and shepherding pull requests.Thanks also to Myron for all his work on two great new features: the newexpectationsyntaxand support for stubbingconstants.rspec-core-2.11.0full changelogEnhancementsSupport multiple --example options. (Daniel Doubrovkine @dblock)Named subject e.g. subject(:article) { Article.new }see http://blog.davidchelimsky.net/2012/05/13/spec-smell-explicit-use-of-subject/for background.thanks to Bradley Schaefer for suggesting it and Avdi Grimm for almostsuggesting it.config.mock_with and config.expect_with yield custom config object to ablock if givenaids decoupling from rspec-core’s configuationinclude_context and include_examples support a block, which gets eval’din the current context (vs the nested context generated by it_behaves_like).Add config.order = 'random' to the spec_helper.rb generated by rspec--init.Delay the loading of DRb (Myron Marston).Limit monkey patching of describe onto just the objects that need it ratherthan every object in the system (Myron Marston).Bug fixesSupport alternative path separators. For example, on Windows, you can now dothis: rspec spec\subdir. (Jarmo Pertman @jarmo)When an example raises an error and an after or around hook does aswell, print out the hook error. Previously, the error was silenced andthe user got no feedback about what happened. (Myron Marston)--require and -I are merged among different configuration sources (AndyLindeman)Delegate to mocha methods instead of aliasing them in mocha adapter.rspec-expectations-2.11.0full changelogEnhancementsExpand expect syntax so that it supports expections on bare valuesin addition to blocks (Myron Marston).Add configuration options to control available expectation syntaxes(Myron Marston):RSpec.configuration.expect_with(:rspec) { |c| c.syntax = :expect }RSpec.configuration.expect_with(:rspec) { |c| c.syntax = :should }RSpec.configuration.expect_with(:rspec) { |c| c.syntax = [:should, :expect] }RSpec.configuration.add_should_and_should_not_to DelegatorBug fixesAllow only Numeric values to be the “actual” in the be_within matcher.This prevents confusing error messages. (Su Zhang @zhangsu)Define should and should_not on BasicObject rather than Kernelon 1.9. This makes should and should_not work properly withBasicObject-subclassed proxy objects like Delegator. (MyronMarston)rspec-mocks-2.11.0full changelogEnhancementsexpose ArgumentListMatcher as a formal APIsupports use by 3rd party mock frameworks like SurrogateAdd stub_const API to stub constants for the duration of anexample (Myron Marston).Bug fixesFix regression of edge case behavior. double.should_receive(:foo) { a }was causing a NoMethodError when double.stub(:foo).and_return(a, b)had been setup before (Myron Marston).Infinite loop generated by using any_instance and dup. (Sidu Ponnappa @kaiwren)double.should_receive(:foo).at_least(:once).and_return(a) always returns aeven if :foo is already stubbed.Prevent infinite loop when interpolating a null double into a stringas an integer ("%i" % double.as_null_object). (Myron Marston)Fix should_receive so that null object behavior (e.g. returningself) is preserved if no implementation is given (Myron Marston).Fix and_raise so that it raises RuntimeError rather thanException by default, just like ruby does. (Andrew Marshall)rspec-rails-2.11.0full changelogEnhancementsThe generated spec/spec_helper.rb sets config.order = "random" so thatspecs run in random order by default.rename render_template to have_rendered (and alias to render_templatefor backward compatibility)Bug fixes“uninitialized constant” errors are avoided when using using gems likerspec-rails-uncommitted that define Rspec::Rails before rspec-railsloads (Andy Lindeman) Spec smell: explicit use of subject May 13th, 2012 | Comments TL;DRExplicit use of the “subject” abstraction is a code smell, and should berefactored to use a more intention revealing name whenever possible.One linersrspec-core supports a one-liner syntax to reduce the noise of commonrequirements like validations:article_spec.rb123describe Article do it { should validate_presence_of(:title) }endWithout support for this syntax, the same example might look like this:article_spec.rb123456describe Article do it "validates presence of :title" do article = Article.new article.should validate_presence_of(:title) endendThe benefit of this more verbose example is that it we can read it andunderstand all the parts right away: an object is initialized and assigned to alocal variable, then that variable is used for an expectation.The benefit of the one-liner is that it’s terse and expressive, but that comesat a cost: you can’t see what the expectation is being evaluated against, so youhave to understand some underlying mechanics in order to isolate/understand afailure.The subject abstractionBehind the scenes, the one-liner uses a “subject” abstraction supported by twomethods named subject. One is a class method on ExampleGroup, used todeclare the “subject” of all of the examples in the group:article_spec.rb1234describe Article do subject { Article.new } # ...endThe other is an instance method on ExampleGroup. The first time it is calledwithin an example the block passed to the class’ subject method is evaluatedand its result memoized, returning the same value from that and each subsequentsubject call:article_spec.rb123456describe Article do # ... it "validates presence of :title" do subject.should validate_presence_of(:title) endendHere is what they look like together:article_spec.rb12345678# not recommendeddescribe Article do subject { Article.new } it "validates presence of :title" do subject.should validate_presence_of(:title) endendThe problem with this example is that the word “subject” is not very intentionrevealing. That might not appear problematic in this small example because youcan see the declaration on line 3 and the reference on line 6. But when thisgroup grows to where you have to scroll up from the reference to find thedeclaration, the generic nature of the word “subject” becomes a hinderance tounderstanding and slows you down.In this case, we’d be better served by using a method (or a let declaration)with an intention revealing name:article_spec.rb1234567describe Article do def article; Article.new; end it "validates presence of :title" do article.should validate_presence_of(:title) endendIf we can do that, you might wonder why we have “subject” at all. Well, it wasoriginally designed to never be seen:Implicit subjectNote in the example with subject { Article.new }, that the subject declaration is initializing anArticle with no args. Since RSpec knows that the first argument todescribe is the Article class, it can store a similar block in thebackground as a default, implicit subject declaration, leaving us with:article_spec.rb123456# refactoring toward implicit step 1describe Article do it "validates presence of :title" do subject.should validate_presence_of(:title) endendThat’s a little better, but now subject appears out of nowhere in theexample, leaving the reader to wonder where it came from. To remove the needfor explicitly referencing subject, the example delegates should andshould_not to subject when it is, itself, the receiver:article_spec.rb123456# refactoring toward implicit step 2describe Article do it "validates presence of :title" do should validate_presence_of(:title) endendStarting that line with “should” seems a bit odd though, so the final step is todo it all in one line:article_spec.rb123describe Article do it { should validate_presence_of(:title) }endNow we have a completely implicit subject, and the result reads quite nicely inboth the code and the output when run with --format documentation:Article should validate presence of :titleWe still need to trust that something is doing some work for us but it’s alloperating at the same level of abstraction, so we don’t have to try tointerpret half of the functionality.Avoid explicit use of subjectIntention revealing names are crucial if you want to be able to quickly scanand understand code as you navigate around different parts of a system. This isas true for specs as it is for implementation, and the generic nature of theword “subject” makes it a poor choice when a more intention revealing name canbe used.Is an explicit subject ever OK?Guidelines are guidelines; YMMV. In general I would recommend that if there isa reasonable way to use an intention revealing name instead of “subject”, youshould. The only use case I can think of in RSpec in which another name can’tbe used is the one liner syntax:american_citizen_spec.rb12345678describe AmericanCitizen do context "18 years of age" do subject { Person.new(:birthdate => 18.years.ago) } it { should be_able_to(:vote) } it { should be_able_to(:enlist) } it { should_not be_able_to(:drink) } # srsly? endendHere we have to use subject because that’s the only way to tell RSpec whereto send should and should_not. In my opinion, any other explicit appearanceof subject can and should be refactored to use an intention revealing name.Update 2012-05-15Based on feedback on this post, I added support for a “named subject,” whichlets you reference the declared subject implicitly in one-liners and with anintention revealing name in standard examples:checking_account_spec.rb1234567describe CheckingAccount, "with a non-zero starting balance" do subject(:account) { CheckingAccount.new(Money.new(50, :USD)) } it { should_not be_overdrawn } it "has a balance equal to the starting balance" do account.balance.should eq(Money.new(50, :USD)) endendThis will be released with rspec-core-2.11. Keep your eyes out for it! rspec-mocks and rspec-rails-2.10.1 are released! May 5th, 2012 | Comments These are patch releases recommended for anybody who has already upgraded to 2.10.rspec-mocks-2.10.1full changelogBug fixesfix regression of edge case behaviorfixed failure of object.should_receive(:message).at_least(0).times.and_return valuefixed failure of object.should_not_receive(:message).and_return valuerspec-rails-2.10.1full changelogBug fixesfix regression introduced in 2.10.0 that broke integration with Devise rspec-2.10 is released! May 3rd, 2012 | Comments API Docs (RDoc)http://rubydoc.info/gems/rspec-corehttp://rubydoc.info/gems/rspec-expectationshttp://rubydoc.info/gems/rspec-mockshttp://rubydoc.info/gems/rspec-railsCucumber docshttp://relishapp.com/rspec/rspec-corehttp://relishapp.com/rspec/rspec-expectationshttp://relishapp.com/rspec/rspec-mockshttp://relishapp.com/rspec/rspec-railsrspec-core-2.10.0full changelogEnhancementsAdd prepend_before and append_after hooks (preethiramdev)intended for extension libsrestores rspec-1 behaviorReporting of profiled examples (moro)Report the total amount of time taken for the top slowest examples.Report what percentage the slowest examples took from the total runtime.Bug fixesProperly parse SPEC_OPTS options.example.description returns the location of the example if there is noexplicit description or matcher-generated description.RDoc fixes (Grzegorz Świrski)Do not modify example ancestry when dumping errors (Michael Grosser)rspec-expectations-2.10.0full changelogEnhancementsAdd new start_with and end_with matchers (Jeremy Wadsack)Add new matchers for specifying yields (Myron Marson):expect {...}.to yield_controlexpect {...}.to yield_with_args(1, 2, 3)expect {...}.to yield_with_no_argsexpect {...}.to yield_successive_args(1, 2, 3)match_unless_raises takes multiple exception argsBug fixesFix be_within matcher to be inclusive of delta.Fix message-specific specs to pass on Rubinius (John Firebaugh)rspec-mocks-2.10.0full changelogBug fixesfail fast when an exactly or at_most expectation is exceededrspec-rails-2.10.0full changelogBug fixesrender_views called in a spec can now override the config setting. (martinsvalin)Fix render_views for anonymous controllers on 1.8.7. (hudge, mudge)Eliminate use of deprecated process_view_pathsFix false negatives when using route_to matcher with should_notcontroller is no longer nil in config.before hooksChange request.path_parameters keys to symbols to match real Railsenvironment (Nathan Broadbent)Silence deprecation warnings in pre-2.9 generated view specs(Jonathan del Strother) rspec-expectations-2.9.1 is released! Apr 3rd, 2012 | Comments This is a bug-fix only release, and is recommended for everybody using rspec-2.9.full changelogBug fixesProvide a helpful message if the diff between two objects is empty.Fix bug diffing single strings with multiline strings.Fix for error with using custom matchers inside other custom matchers(mirasrael)Fix using execution context methods in nested DSL matchers (mirasrael) rspec-2.9.0 is released! Mar 17th, 2012 | Comments rspec-2.9.0 is released wtih lots of bug fixes and a few minor feature improvements as well. Enjoy!rspec-core-2.9.0 / 2012-03-17full changelogEnhancementsSupport for “X minutes X seconds” spec run duration in formatter. (uzzz)Strip whitespace from group and example names in doc formatter.Removed spork-0.9 shim. If you’re using spork-0.8.x, you’ll need to upgradeto 0.9.0.Bug fixesRestore --full_backtrace optionEnsure that values passed to config.filter_run are respected when runningover DRb (using spork).Ensure shared example groups are reset after a run (as example groups are).Remove rescue false from calls to filters represented as ProcsEnsure described_class gets the closest constant (pyromaniac)In “autorun”, don’t run the specs in the at_exit hook if there was anexception (most likely due to a SyntaxError). (sunaku)Don’t extend groups with modules already used to extend ancestor groups.its correctly memoizes nil or false values (Yamada Masaki)rspec-expectations-2.9.0 / 2012-03-17full changelogEnhancementsMove built-in matcher classes to RSpec::Matchers::BuiltIn to reduce pollutionof RSpec::Matchers (which is included in every example).Autoload files with matcher classes to improve load time.Bug fixesAlign respond_to? and method_missing in DSL-defined matchers.Clear out user-defined instance variables between invocations of DSL-definedmatchers.Dup the instance of a DSL generated matcher so its state is not changed bysubsequent invocations.Treat expected args consistently across positive and negative expectations(thanks to Ralf Kistner for the heads up)rspec-mocks-2.9.0 / 2012-03-17full changelogEnhancementsSupport order constraints across objects (preethiramdev)Bug fixesAllow a as_null_object to be passed to withPass proc to block passed to stub (Aubrey Rhodes)Initialize child message expectation args to match any args (#109 –preethiramdev)rspec-rails-2.9.0 / 2012-03-17full changelogEnhancmentsadd description method to RouteToMatcher (John Wulff)Run “db:test:clone_structure” instead of “db:test:prepare” if Active Record’sschema format is “:sql”. (Andrey Voronkov)Bug fixesmock_model(XXX).as_null_object.unknown_method returns self againGenerated view specs use different IDs for each attribute. Validations are behavior, associations are structure Feb 12th, 2012 | Comments TL;DR:TDD is about specifying behavior, not structure.Validations are behavior, and should be specified.Associations are structure, and need not be.DisclaimerThis is my personal viewpoint, though it is not mine alone. YMMV.DeclarationsActiveRecord provides a declarative interface for describing the structure andbehavior of a model:article.rb1234class Article