search for: ekenosen

...printed for slow specs. When using color, I want the entire progress bar printed in green if everything is good, yellow if there has been a warning, and red if there has been an error. And then I remembered that rspec makes it super easy to write your own custom formatter. So I did. :-) http://ekenosen.net/nick/devblog/2008/12/better-progress-bar-for-rspec/ Let me know what you think. Is this useful to anyone? Any ideas for improvements? -- Nick

...I can take while the features are running :) It''s in my fork, in the coverage_formatter branch: http://github.com/mattwynne/cucumber/tree/master It will dump failing feature, scenario, step and the exception as the features run. No specs for it, it''s just a spike. [1]http://ekenosen.net/nick/devblog/2008/12/better-progress-bar-for-rspec/ Matt Wynne http://blog.mattwynne.net http://www.songkick.com

On 5/28/07, David Chelimsky <dchelimsky at gmail.com> wrote: > The behaviour you''re trying to describe is that the User should > require that passwords bear certain qualities - in this case a length > between 5 and 40. So you need to ask yourself how the User should > behave when this requirement is violated, and then specify that it > behaves that way. > >

Just curious - now that rspec (as of 0.9) let''s you choose your mock framework, how many of you are actually using (or planning to use) mocha or flexmock? Anybody planning to use any other mock framework besides rspec, mocha or flexmock? Thanks, David

So, I''ve been following the recommendations for controller specs here: http://blog.davidchelimsky.net/articles/2006/11/09/tutorial-rspec-stubs-and-mocks Most notably: a single expectation per specify block; the setup block contains only stubs; mock expectations each get their own specify block. (I''m still using 0.8, so I haven''t gotten the describe/it goodness yet.) I

>Comment By: Luis Lavena (luislavena) > Date: 2007-05-04 23:37 > describe "An Asset" do > before(:each) do > @asset = Asset.new > end > > it { @asset.should have_one(:attachment) } > it { @asset.should have_present(:something) } > end Food for thought on these. I like have_one a lot. It speaks to me as a Rails developer and I think it speaks to

As of now, I can create a project from Git repository, run a builder on it, and even run the dashboard. Build pages look ugly because build.label in git is very long, a bunch of unit tests is failing, and I had to disable some functionality, namely displaying source control errors in the dashboard. SourceControl::AbstractAdapter#execute_with_error_log (formerly known as

I''ve got the following expectation: response.should redirect_to(:action => "new", :video_id => "1", :process_id => "2", :origin_id => "3") that fails with this error message: expected redirect to {:video_id=>"1", :process_id=>"2", :origin_id=>"3", :action=>"new"}, got redirect to

Test First Development is great...But should you use it when you are adding classes/methods on to external library that doesn''t have an extensive test suite? I noticed that the rspec plugin for autotest has no specs. David Chemlinsky said something to the list a while back that has been stewing in my subconscious - that you develop software differently using Test First

On 4/27/07, David Chelimsky <dchelimsky at gmail.com> wrote: > Any other suggestions? > > In general, I''m much more inclined to favor an additional parameter > passed to #it over a new method name. Since I suggested in the other thread that perhaps during_event and on_event could append text to the spec string, here''s another similar (but simpler) suggestion