From kou at cozmixng.org  Thu Mar  3 07:37:20 2011
From: kou at cozmixng.org (Kouhei Sutou)
Date: Thu, 03 Mar 2011 21:37:20 +0900 (JST)
Subject: [test-unit-users-en:00050] Re: Should tests be sandboxed by default?
In-Reply-To: <AANLkTikB5b6uE4_HVkM9O_MMYi2qVhauoJ-fVCOfiXod@mail.gmail.com>
References: <1298419580.1861.71.camel@globe-hw4whh1>
	<20110225.185339.2183530227841205923.kou@cozmixng.org>
	<AANLkTikB5b6uE4_HVkM9O_MMYi2qVhauoJ-fVCOfiXod@mail.gmail.com>
Message-ID: <20110303.213720.1146678730695568036.kou@cozmixng.org>

Hi,

In <AANLkTikB5b6uE4_HVkM9O_MMYi2qVhauoJ-fVCOfiXod at mail.gmail.com>
  "[test-unit-users-en:00047] Re: Should tests be sandboxed by default?" on Fri, 25 Feb 2011 12:26:43 -0700,
  Daniel Berger <djberg96 at gmail.com> wrote:

>>> What if we wrap all tests in a sandbox somehow? I see a few "sandbox"
>>> gems out on rubygems. Would using them be an option?
>>
>> Could you tell us the gems? We may support one of them.
> 
> There's a couple out there that may fit, though I haven't deeply
> investigated any of these. I see a "sandbox" library, that's a local
> filesystem wrapper in /tmp I think. There's also a couple "safe"
> libraries, e.g. safe_shell, safe_eval, and Safebox that may do the
> job.

Thanks for your report.
When you investigate depply and find the best gem to be
supported, please tell me. :-)

>>> Or do you feel that this is up to the gem-testers people to handle?
>>
>> It seems that "sandbox" is helpful for non gem-testers
>> people.
> 
> True enough. :)

I want to support pararell testing with multi Ruby
processes. "sandbox" library will be helpful for it.


Thanks,
--
kou

From djberg96 at gmail.com  Sat Mar  5 23:59:25 2011
From: djberg96 at gmail.com (Daniel Berger)
Date: Sat, 5 Mar 2011 21:59:25 -0700
Subject: [test-unit-users-en:00051] assert_respond_to and private methods
Message-ID: <AANLkTikL_E4HK4Gags6v1vZUgwXEGyTwWyUAuX79ppqE@mail.gmail.com>

Hi,

I happen to be in a situation where I'm mixing in a module that
contains private methods. These are methods that are meant to be used
internally only by library writers, not externally by objects.

While Object#respond_to? accepts an optional second argument, the
assert_respond_to method doesn't give me the choice to test for
private methods.

Suggestions?

Regards,

Dan

From kou at cozmixng.org  Sun Mar  6 07:17:35 2011
From: kou at cozmixng.org (Kouhei Sutou)
Date: Sun, 06 Mar 2011 21:17:35 +0900 (JST)
Subject: [test-unit-users-en:00052] Re: assert_respond_to and private methods
In-Reply-To: <AANLkTikL_E4HK4Gags6v1vZUgwXEGyTwWyUAuX79ppqE@mail.gmail.com>
References: <AANLkTikL_E4HK4Gags6v1vZUgwXEGyTwWyUAuX79ppqE@mail.gmail.com>
Message-ID: <20110306.211735.73293218031483261.kou@cozmixng.org>

Hi,

In <AANLkTikL_E4HK4Gags6v1vZUgwXEGyTwWyUAuX79ppqE at mail.gmail.com>
  "[test-unit-users-en:00051] assert_respond_to and private methods" on Sat, 5 Mar 2011 21:59:25 -0700,
  Daniel Berger <djberg96 at gmail.com> wrote:

> I happen to be in a situation where I'm mixing in a module that
> contains private methods. These are methods that are meant to be used
> internally only by library writers, not externally by objects.
> 
> While Object#respond_to? accepts an optional second argument, the
> assert_respond_to method doesn't give me the choice to test for
> private methods.
> 
> Suggestions?

Could you give us an example source and test codes?
We may suggest you a solution.


Thanks,
--
kou

From djberg96 at gmail.com  Sun Mar  6 08:31:14 2011
From: djberg96 at gmail.com (Daniel Berger)
Date: Sun, 06 Mar 2011 06:31:14 -0700
Subject: [test-unit-users-en:00053] Re: assert_respond_to and private methods
In-Reply-To: <20110306.211735.73293218031483261.kou@cozmixng.org>
References: <AANLkTikL_E4HK4Gags6v1vZUgwXEGyTwWyUAuX79ppqE@mail.gmail.com>
	<20110306.211735.73293218031483261.kou@cozmixng.org>
Message-ID: <4D738CA2.1040301@gmail.com>

On 3/6/11 5:17 AM, Kouhei Sutou wrote:
> Hi,
>
> In<AANLkTikL_E4HK4Gags6v1vZUgwXEGyTwWyUAuX79ppqE at mail.gmail.com>
>    "[test-unit-users-en:00051] assert_respond_to and private methods" on Sat, 5 Mar 2011 21:59:25 -0700,
>    Daniel Berger<djberg96 at gmail.com>  wrote:
>
>> I happen to be in a situation where I'm mixing in a module that
>> contains private methods. These are methods that are meant to be used
>> internally only by library writers, not externally by objects.
>>
>> While Object#respond_to? accepts an optional second argument, the
>> assert_respond_to method doesn't give me the choice to test for
>> private methods.
>>
>> Suggestions?
>
> Could you give us an example source and test codes?
> We may suggest you a solution.

For example, let's say my library is a module defined like this:

module DanModule
   private

   def hello
     123
   end
end

And now I want to test that the "hello" method is mixed in:

class MyTest < Test::Unit::TestCase
   include DanModule

   test "hello method exists" do
     assert_respond_to(self, :hello)
   end
end

That will fail because respond_to checks don't check against private 
methods by default. My workaround for now is to do this:

assert_true(self.private_methods.include?("hello"))

I'm just wondering if there's a nicer way.

Regards,

Dan

From kou at cozmixng.org  Mon Mar  7 06:48:03 2011
From: kou at cozmixng.org (Kouhei Sutou)
Date: Mon, 07 Mar 2011 20:48:03 +0900 (JST)
Subject: [test-unit-users-en:00054] Re: assert_respond_to and private methods
In-Reply-To: <4D738CA2.1040301@gmail.com>
References: <AANLkTikL_E4HK4Gags6v1vZUgwXEGyTwWyUAuX79ppqE@mail.gmail.com>
	<20110306.211735.73293218031483261.kou@cozmixng.org>
	<4D738CA2.1040301@gmail.com>
Message-ID: <20110307.204803.1233761139407685730.kou@cozmixng.org>

Hi,

In <4D738CA2.1040301 at gmail.com>
  "[test-unit-users-en:00053] Re: assert_respond_to and private methods" on Sun, 06 Mar 2011 06:31:14 -0700,
  Daniel Berger <djberg96 at gmail.com> wrote:

>> Could you give us an example source and test codes?
>> We may suggest you a solution.
> 
> For example, let's say my library is a module defined like
> this:

Thanks for providing an example.

> module DanModule
>   private
> 
>   def hello
>     123
>   end
> end
> 
> And now I want to test that the "hello" method is mixed in:
> 
> class MyTest < Test::Unit::TestCase
>   include DanModule
> 
>   test "hello method exists" do
>     assert_respond_to(self, :hello)
>   end
> end
> 
> That will fail because respond_to checks don't check against
> private methods by default. My workaround for now is to do
> this:
> 
> assert_true(self.private_methods.include?("hello"))
> 
> I'm just wondering if there's a nicer way.

For this example, I'll call hello method to test:

  assert_equal(123, hello)

I may use different way for another example.


Thanks,
--
kou

From dberger at globe.gov  Tue Mar 15 13:00:33 2011
From: dberger at globe.gov (Daniel Berger)
Date: Tue, 15 Mar 2011 11:00:33 -0600
Subject: [test-unit-users-en:00055] Yielding test objects within test methods
Message-ID: <1300208433.26257.95.camel@globe-hw4whh1>

Hi,

A co-worker asked me today if there was a way to get a test name from
within the test itself. He wanted this for logging. I took a guess and
tried this:

require 'rubygems'
gem 'test-unit'
require 'test/unit'

class TC_Foo < Test::Unit::TestCase
  def setup
    @arr = []
  end

  test "array is an array" do
    assert_true(@arr.is_a?(Array))
  end

  test "array is size zero" do |t|
    assert_true(@arr.empty?)
  end

  def teardown
    @arr = []
  end
end

Oddly the second test (where I use a block argument) doesn't seem to get
run at all.

Could the declarative form be made to yield back the test object? So
that users can get at the test name?

Regards,

Dan


From kou at cozmixng.org  Thu Mar 17 08:26:45 2011
From: kou at cozmixng.org (Kouhei Sutou)
Date: Thu, 17 Mar 2011 21:26:45 +0900 (JST)
Subject: [test-unit-users-en:00056] Re: Yielding test objects within test
	methods
Message-ID: <20110317.212645.665018056015762731.kou@cozmixng.org>

Hi,

> class TC_Foo < Test::Unit::TestCase
>   def setup
>     @arr = []
>   end

>   test "array is an array" do
>     assert_true(@arr.is_a?(Array))
>   end

>   test "array is size zero" do |t|
>     assert_true(@arr.empty?)
>   end

>   def teardown
>     @arr = []
>   end
> end

> Oddly the second test (where I use a block argument) doesn't seem to get
> run at all.

Test method should be no argument. If a test method requires
one or more arguments, the method is ignored.

> Could the declarative form be made to yield back the test object? So
> that users can get at the test name?

You can access by test name by @method_name but the API is
not stable. It may be changed but there is a no plan to
change it for now.


Thanks,
--
kou

From sunaku at gmail.com  Wed Mar 30 12:06:38 2011
From: sunaku at gmail.com (Suraj Kurapati)
Date: Wed, 30 Mar 2011 09:06:38 -0700
Subject: [test-unit-users-en:00057] [ANN] test-unit-must 0.0.1
Message-ID: <AANLkTi=+d=wDszah1+q5NcJr=Pc8GTneRPK8SsOe_vVu@mail.gmail.com>

test-unit-must - Selfish "must" assertions for Test::Unit
                 https://github.com/sunaku/test-unit-must

???????????????????????????????????????????????????????????

What is it?

test-unit-must is a set of assertions for Test::Unit that
treat the receiver of an assertion method call as the
subject of the assertion. In other words, these are
MiniTest::Spec-style assertions, but their names only begin
with "must_" or "must_not_"; there is no "wont_" or
"refute_" prefix.

???????????????????????????????????????????????????????????

Compatibility

test-unit-must was designed for Test::Unit 2.2.0. However,
I found that it works just as well with the MiniTest
library bundled in Ruby 1.9.2! :-) In addition, it politely
accomodates Rails 3's ActiveSupport extensions to
Test::Unit.

???????????????????????????????????????????????????????????

Installation

As a Ruby gem:

gem install test-unit-must

As a Git clone:

git clone git://github.com/sunaku/test-unit-must

???????????????????????????????????????????????????????????

Usage

Load the library somewhere in your test suite, such as in
your test helper:

require 'test/unit/must'

In your test methods, call must_* methods on any Ruby
object you like:

class ExampleTest < Test::Unit::TestCase
  def test_example
    ary = (1..10).to_a

    ary.must_not_be_empty
    assert_not_empty ary

    ary.length.must_equal 10
    assert_equal 10, ary.length

    ary.must_not_equal []
    assert_not_equal [], ary

    ary.first.must_equal 1
    assert_equal 1, ary.first

    (ary[1] * 5).must_equal ary.length
    assert_equal ary.length, (ary[1] * 5)

    # and so on ...
  end
end

Note that you can still use traditional Test::Unit
assertions freely.

???????????????????????????????????????????????????????????

Reference

Here is the mapping from test-unit-must assertions to
Test::Unit assertions.

def must_alias_method alias_name, original_name, message=nil
    assert_alias_method self, alias_name, original_name, message

def must_be_boolean message=nil
    assert_boolean self, message

def must_compare operator, expected, message=nil
    assert_compare expected, operator, self, message

def must_define_constant constant_name, message=nil
    assert_const_defined self, constant_name, message

def must_not_define_constant constant_name, message=nil
    assert_not_const_defined self, constant_name, message

def must_be_empty message=nil
    assert_empty self, message

def must_not_be_empty message=nil
    assert_not_empty self, message

def must_equal expected, message=nil
    assert_equal expected, self, message

def must_not_equal expected, message=nil
    assert_not_equal expected, self, message

def must_be_false message=nil
    assert_false self, message

def must_be_in_delta expected_float, delta=0.001, message=nil
    assert_in_delta expected_float, self, delta, message

def must_not_be_in_delta expected_float, delta=0.001, message=nil
    assert_not_in_delta expected_float, self, delta, message

def must_be_in_epsilon expected_float, epsilon=0.001, message=nil
    assert_in_epsilon expected_float, self, epsilon, message

def must_not_be_in_epsilon expected_float, epsilon=0.001, message=nil
    assert_not_in_epsilon expected_float, self, epsilon, message

def must_include member, message=nil
    assert_include self, member, message

def must_not_include member, message=nil
    assert_not_include self, member, message

def must_be_instance_of klass, message=nil
    assert_instance_of klass, self, message

def must_be_kind_of klass, message=nil
    assert_kind_of klass, self, message

def must_match pattern, message=nil
    assert_match pattern, self, message

def must_not_match pattern, message=nil
    assert_not_match pattern, self, message

def must_be_nil message=nil
    assert_nil self, message

def must_not_be_nil message=nil
    assert_not_nil self, message

def must_operate operator, argument, message=nil
    assert_operator self, operator, argument, message

def must_raise *arguments
    assert_raise *arguments, &self

def must_raise_kind_of *arguments
    assert_raise_kind_of *arguments, &self

def must_raise_message expected, message=nil
    assert_raise_message expected, message, &self

def must_raise_nothing *arguments
    assert_nothing_raised *arguments, &self

def must_be expected, message=nil
    assert_same expected, self, message

def must_not_be expected, message=nil
    assert_not_same expected, self, message

def must_receive send_array, message=nil
    assert_send [self] + send_array, message

def must_not_receive send_array, message=nil
    assert_not_send [self] + send_array, message

def must_respond_to method, message=nil
    assert_respond_to self, method, message

def must_not_respond_to method, message=nil
    assert_not_respond_to self, method, message

def must_throw expected_object, message=nil
    assert_throw expected_object, message, &self

def must_throw_nothing *arguments
    assert_nothing_thrown *arguments, &self

def must_be_true message=nil
    assert_true self, message

???????????????????????????????????????????????????????????

License

Released under the ISC license. See the lib/test/unit/
must.rb file.