Displaying 20 results from an estimated 100 matches similar to: "expectations on stubs (stubba) or mock methods on existing classes?"
2006 Sep 13
2
Problem with RSpec and Mocha/Stubba
I''ve recently upgraded to the latest versions of Mocha and RSpec
(0.3.2 and 0.6.3 respectively) and I''m no longer able to use Mocha/
Stubba with RSpec. Its actually only Stubba I''m interested in as I
use RSpec''s built-in mocking library.
I require stubba in my spec file but whenever I try and run my spec
it fails with the error:
Unintialized constant
2006 Dec 14
1
Patch: make rdoc of lib/mocha/object.rb instead of lib/stubba/object.rb
Index: Rakefile
===================================================================
--- Rakefile (revision 73)
+++ Rakefile (working copy)
@@ -23,7 +23,7 @@
task.rdoc_dir = ''doc''
task.template = "html_with_google_analytics"
task.options << "--line-numbers" << "--inline-source"
-
2006 Oct 25
5
Mocha, Stubba and RSpec
Hi,
I''ve been reading with interest the threads trying to integrate Mocha
and Stubba with RSpec. So far, I''ve made the two changes in
spec_helper.rb suggested, but discovered another one that neither of
the archives mentions:
If you use traditional mocking: object = mock or the stub shortcut
: object = stub(:method => :result), you run into namespace conflicts
with
2006 Sep 22
2
I''m misunderstanding how stubs works
We''re still just starting out with Mocha/Stubba, so please forgive any
newbie errors.
I''m using "stubs" to test some realtime functions, to control exactly which
time is returned from Time.now. I would expect the following test to pass:
def test_two_stubs
t = Time.now - 60
Time.stubs(:now).returns(t)
start_time = Time.now
t += 20
2006 Dec 02
3
Scoping expectations and more ...
Hello!
I''m new to Mocha and through experimentation I found out something
that is not explicitly stated in the documentation: If you need to
mock the same function call with different parameters and results, you
can set the scope of expectations with a begin ... end block.
I also made up an example on how to expect more than one function call
with different parameters and return values.
2006 Nov 21
5
stubbing in development environment
Hi guys.
Quite happy with mocha for testing. It''s been a bit of an eye opener
for me, and I expect to begin using it heavily.
One other thing I''d like to do is stub out particular class methods in
development. Is there a way I can do this with mocha?
Jason
2006 Dec 14
3
Stubbing constructiors
This works:
class X
def X.initialize( stuff )
end
end
X.initialize("bla")
However stubbing it doesn,t:
require ''test/unit''
require ''stubba''
class X
def X.initialize( stuff )
end
end
class XTest < Test::Unit::TestCase
def test_
X.stubs(:initialize).with("bla")
2007 Apr 11
1
Fwd: [ mocha-Bugs-5892 ] Using a setup method in test_case_class destroys subsequent test cases
---------- Forwarded message ----------
From: noreply at rubyforge.org <noreply at rubyforge.org>
Date: 11-Apr-2007 15:24
Subject: [ mocha-Bugs-5892 ] Using a setup method in test_case_class
destroys subsequent test cases
To: noreply at rubyforge.org
Bugs item #5892, was opened at 2006-09-25 07:49
You can respond by visiting:
2006 Sep 25
3
Problem stubbing instances referred to by constants
Hi James,
An instance retains its mocha between tests if that instance is
pointed to by a constant. The simplest failing test is something like
(add as a new file in mocha/test)..
#--code--
require File.join(File.dirname(__FILE__), "test_helper")
require ''stubba''
class WemStubbaTest < Test::Unit::TestCase
Arr = [1, 2, 3]
def test_a
2008 Jan 20
2
Bug #17118 - expectations should take precedence over stubs
I wanted to draw attention to this bug report [A] which highlights a change
that was made between Mocha 0.4 and 0.5.
It may have lead to tests which pass unexpectedly. Does my explanation
(below) make sense to people?
It feels like we should at least add some warnings to the documentation.
You are correct that this behaviour did change between Mocha v0.4.0 and
> v0.5.0 (in revision 115).
2006 Sep 03
1
Slimmed down version for inclusion in Rails?
I''m pushing a major overhaul in testing the Rails codebase. Mocha and
stubba make my life easy so that''s what I''m using. The first major
patch using them is in RailTies
(http://dev.rubyonrails.org/ticket/5970) now. I spoke to DHH today
about using it in the other libraries and I think it''ll be ok, but
they really want to include as little code as needed. I
2006 Sep 18
2
Mocha + Selenium-on-rails loading problem ?
Hello All,
I need to stub two class methods before a selenium call.
The .rsel is :
require ''mocha''
SalesConfigWork.stubs(:load_work_data)
SalesConfigWork.stubs(:delete_work_data)
setup :fixtures => :sales_config_works
open "/"
The Selenium test runner result is :
undefined method `stubs'' for SalesConfigWork:Class
Extracted source (around line *#0*):
2007 Apr 11
0
Fwd: [ mocha-Feature Requests-5856 ] Stubbing of private methods should be allowed
---------- Forwarded message ----------
From: noreply at rubyforge.org <noreply at rubyforge.org>
Date: 11-Apr-2007 15:31
Subject: [ mocha-Feature Requests-5856 ] Stubbing of private methods should
be allowed
To: noreply at rubyforge.org
Feature Requests item #5856, was opened at 2006-09-22 17:03
You can respond by visiting:
2006 Dec 15
0
Fwd: Re: Re: [HOWTO] Edgemocha
---------- Forwarded message ----------
From: James Mead <jamesmead44 at gmail.com>
Date: 15-Dec-2006 17:37
Subject: Re: Re: [HOWTO] Edgemocha
To: John Pywtorak <jpywtora at calpoly.edu>
On 15/12/06, John Pywtorak <jpywtora at calpoly.edu> wrote:
> Compare
> ~$ sudo gem install mocha
> Attempting local installation of ''mocha''
> Successfully
2006 Nov 10
3
Stubbing Time.now in trunk
I''m a big fan of stubbing Time.now so it returns a known value. I used
to be able to use stubba and say:
@time_now = Time.parse("Jan 1 2001")
Time.stubs(:now).returns(lambda{@time_now})
However, something in trunk broke that. Fine, rspec''s got its own
stubbing lib now, so I tried switching to that:
@time_now = Time.parse("Jan 1 2001")
2006 Sep 12
4
ActiveRecord Validations - validates_uniqueness_of
Hello,
I''m wanting to use Mocha and Stubba for my tests in place of the
default Rails testing with fixtures.
I have the following class:
class Person < ActiveRecord::Base
validates_uniqueness_of :email
end
and am wondering how I can test to ensure that the
validates_uniqueness_of validation is running.
Any ideas?
-Jonathan
2007 Aug 08
1
Mocking Time, delegating to original object
In my Unit tests, I run into the all-too-common problem of
Time.expects(:now) being called by Benchmark before the method is
unmocked.
Instead of messing around with the teardown order, I decided to modify
the Expectation with a new method, .stops_mocking.
Here are the changes I use, including a few monkey patches to push
relevant objects down to where I want them, all wrapped up in a big
ugly
2007 Jan 24
0
Mocha 0.4 released
So I finally got round to releasing a new
version<http://rubyforge.org/frs/?group_id=1917&release_id=9184>of
Mocha <http://mocha.rubyforge.org/>. Much of the functionality has been
available for some time if you''ve been using the Rails plugin based on
subversion HEAD, but now you can get it in all in a gem (or other package).
The most recent changes centre around allowing
2006 Aug 15
3
Testing deleting files
In unit or functional test, is there a way to check that a file has been
deleted?
It seems that running the test does not really execute deleting files, which
is good because I don''t want it to actually delete the files. But can I
check that the deletion should have been performed in test environment?
thanks,
- reynard
-------------- next part --------------
An HTML attachment was
2006 Aug 14
14
A mock which extends rather than replaces a class?
While running tests, we would like to instrument some of the classes
under test. We still want the classes to do exactly what they currently
do, but we would like them to do more when running in the test
environment.
Clearly we can (and currently do) just extend the objects "on the fly"
where necessary, but this is a bit messy - we''d like some centralised
way to always