Test unit & singleton

How do you get a fresh copy of a singleton between 2 unit test? It
somewhat breaks the principle of a singleton object as I would like to
get a second brand new instance of the object.

Example (pseudo-code):

require ‘singleton’

class MyObject
include Singleton

… Bunch of good stuff

end

if $0 == FILE
require ‘test/unit’

class MyObject_Test
def test_functionality_1
o = MyObject.instance
# … Tests on o, which changes the internal state of o …
end

def test_functionality_2
  o = MyObject.instance # This instance is polluted 
                        # by previous tests
  # ... Tests on o
end

end
end

How would I get rid of the instance created and polluted in test 1 to
start anew in test 2? Should I implement a ‘reset’ method to clear all
states in the singleton object?

Guillaume.

That’s why you want to avoid singletons as much as possible when it
comes to unit testing.

In cases I do need singletons, I usually end up with a regular class
that can be unit tested, and a separate singleton class that simply
delegates all calls to my actual class. Or something similar.

Gennady.

Guillaume Marcais wrote:

···

How do you get a fresh copy of a singleton between 2 unit test? It
somewhat breaks the principle of a singleton object as I would like to
get a second brand new instance of the object.

Example (pseudo-code):

require ‘singleton’

class MyObject
include Singleton

… Bunch of good stuff

end

if $0 == FILE
require ‘test/unit’

class MyObject_Test
def test_functionality_1
o = MyObject.instance
# … Tests on o, which changes the internal state of o …
end

def test_functionality_2
  o = MyObject.instance # This instance is polluted 
                        # by previous tests
  # ... Tests on o
end

end
end

How would I get rid of the instance created and polluted in test 1 to
start anew in test 2? Should I implement a ‘reset’ method to clear all
states in the singleton object?

Guillaume.

That’s why you want to avoid singletons as much as possible when it
comes to unit testing.

Perhaps we should rename singleton.rb to
hardtotest.rb :-/

In cases I do need singletons, I usually end up with a regular class
that can be unit tested, and a separate singleton class that simply
delegates all calls to my actual class. Or something similar.

That would be my suggestion as well.

Nathaniel
Terralien, Inc.

<:((><

···

On May 7, 2004, at 11:09, Gennady wrote:

You could muck with the internals of Singleton to reset its instance, or
write an extension to your class for testing that ‘resets’ the class
to its initialized state.

···

Gennady (gfb@tonesoft.com) wrote:

That’s why you want to avoid singletons as much as possible when it
comes to unit testing.

In cases I do need singletons, I usually end up with a regular class
that can be unit tested, and a separate singleton class that simply
delegates all calls to my actual class. Or something similar.


Eric Hodel - drbrain@segment7.net - http://segment7.net
All messages signed with fingerprint:
FEC2 57F1 D465 EB15 5D6E 7C11 332A 551C 796C 9F04

Gennady wrote:

That’s why you want to avoid singletons as much as possible when it
comes to unit testing.

In cases I do need singletons, I usually end up with a regular class
that can be unit tested, and a separate singleton class that simply
delegates all calls to my actual class. Or something similar.

Suggestion for something similar, w/o the delegation overhead:

Move all functionality of the singleton class into a module. Include
that module in two classes, one which also includes Singleton (for
actual use) and one dummy class for testing. Put the code for the dummy
class in the unit tests themselves, so the application code doesn’t
accidentally use it for anything.

require ‘singleton’
module RealStuff

end
class DummyClass
include RealStuff
end
class RealClass
include RealStuff
include Singleton
end

···


([ Kent Dahl ]/)_ ~ [ http://www.pvv.org/~kentda/ ]/~
))_student_/(( _d L b_/ Master of Science in Technology )
( __õ|õ// ) ) Industrial economics and technology management (
_
/ö____/ (_engineering.discipline=Computer::Technology)

Not really the answer I prefer :frowning:

I’ll follow your advice.

Thanks,
Guillaume.

···

On Fri, 2004-05-07 at 12:29, Nathaniel Talbott wrote:

On May 7, 2004, at 11:09, Gennady wrote:

That’s why you want to avoid singletons as much as possible when it
comes to unit testing.

Perhaps we should rename singleton.rb to
hardtotest.rb :-/

In cases I do need singletons, I usually end up with a regular class
that can be unit tested, and a separate singleton class that simply
delegates all calls to my actual class. Or something similar.

That would be my suggestion as well.

Nathaniel
Terralien, Inc.

<:((><

Thanks to all of you for good suggestions.

Guillaume.

···

Le 8 mai 04, à 05:03, Kent Dahl a écrit :

Gennady wrote:

That’s why you want to avoid singletons as much as possible when it
comes to unit testing.
In cases I do need singletons, I usually end up with a regular class
that can be unit tested, and a separate singleton class that simply
delegates all calls to my actual class. Or something similar.

Suggestion for something similar, w/o the delegation overhead:

Move all functionality of the singleton class into a module. Include
that module in two classes, one which also includes Singleton (for
actual use) and one dummy class for testing. Put the code for the
dummy class in the unit tests themselves, so the application code
doesn’t accidentally use it for anything.

require ‘singleton’
module RealStuff

end
class DummyClass
include RealStuff
end
class RealClass
include RealStuff
include Singleton
end


([ Kent Dahl ]/)_ ~ [ Kent Dahl - Kent Dahl
]
/~
))_student_/(( _d L b_/ Master of Science in Technology )
( __õ|õ// ) ) Industrial economics and technology management (
_
/ö____/ (_engineering.discipline=Computer::Technology)

Guillaume Marcais schrieb:

Thanks to all of you for good suggestions.

Here is another possiblity

···

require ‘singleton’

class MySingletonClass
include Singleton
end

use or test MySingletonClass, in particular

instantiate it …

my_inst = MySingletonClass.instance

make a temporary copy and remove

the current MySingletonClass constant

and reassign it the uninstantiated

temporary copy. The exmaple assumes that

MySingletonClass is defined in the top scope,

furthermore there are obvious complications

if your stuff depends on the inheritance capility

of the Singleton implementation …

class Object
tmp = MySingletonClass.clone
remove_const :MySingletonClass
const_set :MySingletonClass, tmp
end

MySingletonClass is an uninstantiated at

this point …

p (my_inst == MySingletonClass.instance) # false

/Christoph