BDD testing framework without dependencies

classic Classic list List threaded Threaded
25 messages Options
12
Reply | Threaded
Open this post in threaded view
|

BDD testing framework without dependencies

tyrondis
Hi *,

I am looking for a BDD unit testing framework for Lua that has no dependencies, so that I can run my tests inside an embedded system. So far I found https://github.com/mirven/luaspec, but I do not like its syntax.

Is there anything out there with a syntax like Busted (http://olivinelabs.com/busted/), but has no dependencies?

Thanks!
Reply | Threaded
Open this post in threaded view
|

Re: BDD testing framework without dependencies

Julien
Hi,

I'm pretty happy with Telescope[1]: it has mostly the same syntax as
Busted but without any dependencies.

Unfortunately, it does not seem to be maintained anymore[2] but works
flawlessly once the with the linked patch has been applied.

[1] https://github.com/norman/telescope
[2] https://github.com/norman/telescope/pull/24

Le Mon, 22 Aug 2016 14:12:45 +1000,
tyrondis <[hidden email]> a écrit :

> Hi *,
>
> I am looking for a BDD unit testing framework for Lua that has no
> dependencies, so that I can run my tests inside an embedded system.
> So far I found https://github.com/mirven/luaspec, but I do not like
> its syntax.
>
> Is there anything out there with a syntax like Busted
> (http://olivinelabs.com/busted/), but has no dependencies?
>
> Thanks!


Reply | Threaded
Open this post in threaded view
|

Re: BDD testing framework without dependencies

Sean Conner
In reply to this post by tyrondis
It was thus said that the Great tyrondis once stated:
> Hi *,
>
> I am looking for a BDD unit testing framework for Lua that has no
> dependencies, so that I can run my tests inside an embedded system. So far
> I found https://github.com/mirven/luaspec, but I do not like its syntax.
>
> Is there anything out there with a syntax like Busted
> (http://olivinelabs.com/busted/), but has no dependencies?

  Why not just write the tests directly?  I did that for my signal module:

https://github.com/spc476/lua-conmanorg/blob/master/test/signal-test.lua

  The only dependency is the module it's testing.

  -spc (Actually, I'm very puzzled over testing frameworks in general ... )


Reply | Threaded
Open this post in threaded view
|

Re: BDD testing framework without dependencies

Andrew Starks-2

On Mon, Aug 22, 2016 at 17:41 Sean Conner <[hidden email]> wrote:
It was thus said that the Great tyrondis once stated:
> Hi *,
>
> I am looking for a BDD unit testing framework for Lua that has no
> dependencies, so that I can run my tests inside an embedded system. So far
> I found https://github.com/mirven/luaspec, but I do not like its syntax.
>
> Is there anything out there with a syntax like Busted
> (http://olivinelabs.com/busted/), but has no dependencies?

  Why not just write the tests directly?  I did that for my signal module:

https://github.com/spc476/lua-conmanorg/blob/master/test/signal-test.lua

  The only dependency is the module it's testing.

  -spc (Actually, I'm very puzzled over testing frameworks in general ... )




Testing is like logging. It can always be made more complicated.
Reply | Threaded
Open this post in threaded view
|

Re: BDD testing framework without dependencies

Jorge Visca
On 22/08/16 23:29, Andrew Starks wrote:
> Testing is like logging. It can always be made more complicated.

Until you have bugs in you debugging code. As I do.

Reply | Threaded
Open this post in threaded view
|

Re: BDD testing framework without dependencies

Sean Conner
It was thus said that the Great Jorge once stated:
> On 22/08/16 23:29, Andrew Starks wrote:
> >Testing is like logging. It can always be made more complicated.
>
> Until you have bugs in you debugging code. As I do.

  I'm not following.

  You have code, which may have bugs so you want to test it.  You write more
code to test it.  Bugs can then be in the code you wrote intially, or the
testing code you just wrote (two locations).  A framework introduces yet one
more place bugs could reside in---the code you wrote, the testing framework,
or the testing code.

  -spc (You don't trust your own code, but yet, you trust code written by
        a third party to be bug free?)


Reply | Threaded
Open this post in threaded view
|

Re: BDD testing framework without dependencies

Daurnimator
On 23 August 2016 at 13:49, Sean Conner <[hidden email]> wrote:
>   -spc (You don't trust your own code, but yet, you trust code written by
>         a third party to be bug free?)

It's not that you assume it's bug free; but that you hope your bugs
and their bugs are uncorrelated.

Reply | Threaded
Open this post in threaded view
|

Re: BDD testing framework without dependencies

steve donovan
On Tue, Aug 23, 2016 at 6:24 AM, Daurnimator <[hidden email]> wrote:
> It's not that you assume it's bug free; but that you hope your bugs
> and their bugs are uncorrelated.

Ah, good point. An argument for a completely brain dead yet convenient
enough test framework.

Reply | Threaded
Open this post in threaded view
|

Re: BDD testing framework without dependencies

Sean Conner
It was thus said that the Great steve donovan once stated:
> On Tue, Aug 23, 2016 at 6:24 AM, Daurnimator <[hidden email]> wrote:
> > It's not that you assume it's bug free; but that you hope your bugs
> > and their bugs are uncorrelated.
>
> Ah, good point. An argument for a completely brain dead yet convenient
> enough test framework.

  And still I ask---what does a framework buy you that assert() doesn't?
Other than (in my opinion) excessive overhead on a possibly buggy framework?

  -spc (Still puzzled by all this ... )


Reply | Threaded
Open this post in threaded view
|

Re: BDD testing framework without dependencies

Alexey Melnichuk-2
Здравствуйте, Sean.

Вы писали 23 августа 2016 г., 9:11:13:

> It was thus said that the Great steve donovan once stated:
>> On Tue, Aug 23, 2016 at 6:24 AM, Daurnimator <[hidden email]> wrote:
>> > It's not that you assume it's bug free; but that you hope your bugs
>> > and their bugs are uncorrelated.
>>
>> Ah, good point. An argument for a completely brain dead yet convenient
>> enough test framework.

>   And still I ask---what does a framework buy you that assert() doesn't?
> Other than (in my opinion) excessive overhead on a possibly buggy framework?

>   -spc (Still puzzled by all this ... )


My main reasons are:

1. More assert functions and pretty error messages.
e.g. assert_string, assert_pass e.g.
2. Test does not stop if one test case fail and continue execute next.
3. Way to do some init/cleanup tasks before each test
e.g. create table in db or create file in file system

P.S. I use lunitx[1] one.

  [1] https://luarocks.org/modules/dougcurrie/lunitx

--
С уважением,
 Alexey                          mailto:[hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: BDD testing framework without dependencies

steve donovan
In reply to this post by Sean Conner
On Tue, Aug 23, 2016 at 8:11 AM, Sean Conner <[hidden email]> wrote:
>   And still I ask---what does a framework buy you that assert() doesn't?
> Other than (in my opinion) excessive overhead on a possibly buggy framework?

Just a few little helpers go a long way. My favourite of course is
pl.test (164 lines) because I really didn't want an external test
dependency. That's how the rot  starts, of course.  I am also a little
bemused by the fetishization of over-complicated test harnesses.
Clearly this is a wheel that needs to be constantly re-invented.

What IMHO is more important than the testing framework itself is
writing clear tests which might actually be useful to outsiders. I
know the mantra is 'tests are documentation' but this is not
automatically true, no more than wikis spontaneously organizing
themselves.

Reply | Threaded
Open this post in threaded view
|

Re: BDD testing framework without dependencies

Thijs Schreijer
In reply to this post by Sean Conner

> On 23 Aug 2016, at 08:11, Sean Conner <[hidden email]> wrote:
>
> It was thus said that the Great steve donovan once stated:
>> On Tue, Aug 23, 2016 at 6:24 AM, Daurnimator <[hidden email]> wrote:
>>> It's not that you assume it's bug free; but that you hope your bugs
>>> and their bugs are uncorrelated.
>>
>> Ah, good point. An argument for a completely brain dead yet convenient
>> enough test framework.
>
>  And still I ask---what does a framework buy you that assert() doesn't?
> Other than (in my opinion) excessive overhead on a possibly buggy framework?
>
>  -spc (Still puzzled by all this ... )
>
>

lol

Why do you even use Lua, it’s a source of bugs, write your own compiler/interpreter/language, is probably gonna be way better and have lesser bugs.

care about writing your deep tables comparison assertions? roll your own! how about multiple tests using the same setup en teardown. Making sure each test starts as clean as possible. Why re-use, write your own bug free implementations of course!

sorry for the tone in the above, but the thread above is just hilarious.

Those frameworks have been used by many before you and will have far lesser bugs than your own code (no matter how good you code), they probably power thousands of CI runs every day. Yet, you don’t trust them. They’re not bug free, but they’re better anyway.

Only in the simplest of cases one should use the basic asserts, anything beyond that would benefit from a framework (or like the OP, when you have resource constraints maybe)

Sorry Sean, usually read your posts with interest, but this time you made me laugh.

Thijs

Reply | Threaded
Open this post in threaded view
|

Re: BDD testing framework without dependencies

Sean Conner
It was thus said that the Great Thijs Schreijer once stated:

>
> > On 23 Aug 2016, at 08:11, Sean Conner <[hidden email]> wrote:
> >
> > It was thus said that the Great steve donovan once stated:
> >> On Tue, Aug 23, 2016 at 6:24 AM, Daurnimator <[hidden email]> wrote:
> >>> It's not that you assume it's bug free; but that you hope your bugs
> >>> and their bugs are uncorrelated.
> >>
> >> Ah, good point. An argument for a completely brain dead yet convenient
> >> enough test framework.
> >
> >  And still I ask---what does a framework buy you that assert() doesn't?
> > Other than (in my opinion) excessive overhead on a possibly buggy framework?
> >
> >  -spc (Still puzzled by all this ... )
> >
> >
>
> lol
>
> Why do you even use Lua,

  Because it's the first non-BASIC interpreted langauge that wasn't written
by a programmer who hates programming, isn't postmodern line noise, an
opinionated piece of software that distrusts programmers, and is fast and
straightforward [1].

> it’s a source of bugs,

  Yes, I even found one [2].  It got fixed and I was happy.

> write your own compiler/interpreter/language, is probably gonna be way
> better and have lesser bugs.

  Yeah, I've done that too.  Back in college, when I was in my "Forth is
fascinating" phase [3].  Even used it to implement a class project that ran
fine the first time [4].

> care about writing your deep tables comparison assertions? roll your own!

  Ah, like I did for my CBOR [5] implementation? [6]

> how about multiple tests using the same setup en teardown. Making sure
> each test starts as clean as possible. Why re-use, write your own bug free
> implementations of course!
>
> sorry for the tone in the above, but the thread above is just hilarious.

  And I'm *still* puzzled at what a testing framework *buys* you.  I *might*
have created a "framework" to test my CBOR implemetation [7], but to me,
it's just a few functions that does the work.  For instance:

        test('UINT',"00",0)
        test('UINT',"01",1)
        test('UINT',"0A",10)
        test('UINT',"17",23)
        test('UINT',"1818",24)
        test('false',"F4",false)
        test('true',"F5",true)
        test('null',"F6",nil)
        test('BIN',"4401020304","\1\2\3\4")
        test('TEXT',"60","")
        test('TEXT',"6161","a")
        test('TEXT',"6449455446","IETF")
        test('ARRAY',"8301820203820405",{ 1 , { 2 , 3 } , { 4 , 5 }})
        test('ARRAY',"98190102030405060708090a0b0c0d0e0f101112131415161718181819",
                { 1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25})

(tests taken from RFC-7049)

The test function takes as a parameter the encoded type, a hexstring to
describe the encoded value (since it's binary) and the value it represents.
These are simple, and the test() function encodes the value, checks the
result against what it should be (the test() function converts the hexstring
into a binary string), then decodes the encoded value and compares it
against the original.  Perhaps the most complex test is this one:


test('ARRAY',"83d81c80d81d0080",{{},{},{}},
        function()
          local x = {}
          local ref = {}
          return cbor.TYPE.ARRAY(3)
              .. cbor.TYPE.ARRAY(x,ref)
              .. cbor.TYPE.ARRAY(x,ref)
              .. cbor.TYPE.ARRAY({})
        end,
        function(_,v)
          assertf(type(v) == 'table',"_sharedref: wanted table got
%s",type(v))
          assertf(#v == 3,"_sharedref:  wanted a table of three entries")
          assertf(type(v[1]) == 'table',"_sharedref: wanted v[1] as table")
          assertf(type(v[2]) == 'table',"_sharedref: wanged v[2] as table")
          assertf(type(v[3]) == 'table','_sharedref: wanted v[3] as table')
          assertf(v[1] == v[2],"_sharedref: wanted first two tables equal")
         
          return true
        end)

  There are two optional functions that can be passed in, one for encoding
and one for comparing the results of decoding.  In this case, the value
{{},{},{}}, is not actually used, but is included to show kind of what the
result looks like.

  Now, what would a (any) test framework buy me for this?  Please, educate
me!  I can't make you encode the above tests in a testing framework, but I
would like to see it done.  I'm looking at Lua Spec and Busted (both seem
very similar in nature) and frankly, I don't see what:

describe('CBOR encoding/decoding tests',function()
  desscribe('some simple tests',function()
    it('should work',function()
      local bin = hextobin "F4"
      local e   = cbor.encode(false)
      assert.equals(bin,e)
      local d,_,t = cbor.decode(e)
      assert.equals(t,'false')
      assert.equals(d,false)
    end)

    it('should be an array',function()
      local bin = hextobin "8301820203820405"
      local e   = cbor.encode { 1 , { 2 , 3 } , { 4 , 5 } }
      assert.equals(bin,e)
      local d,_,t = cbor.decode(e)
      assert.equals(t,'ARRAY')
      assert.are.same(d,{ 1 , { 2 , 3 } , { 4 , 5 } })
    end)
  end)

  describe('an array of arrays, with some the same array',function()
    it('has an awful amount of overhead with this testing framework',function()
          local bin = hextobin "83d81c80d81d0080"
          local x = {}
          local ref = {}
          local e = cbor.TYPE.ARRAY(3)
              .. cbor.TYPE.ARRAY(x,ref)
              .. cbor.TYPE.ARRAY(x,ref)
              .. cbor.TYPE.ARRAY({})
          assert.equals(bin,e)
          local v,_,t = cbor.decode(e)
          assert.equals(t,"ARRAY")
          assert.equals(type(v) == 'table')
          assert.equals(#v == 3)
          assert.equals(type(v[1]) == 'table')
          assert.equals(type(v[2]) == 'table')
          assert.equals(type(v[3]) == 'table')
          assert.equals(v[1] == v[2])
        end)
      end)
    end)

 ... yeah ... I'm just not seeing the benefit here.

> Those frameworks have been used by many before you and will have far
> lesser bugs than your own code (no matter how good you code),

  My snarky answer to this is: heartbleed.  How long did this escape
detection?  In a library how many people used?  For how critical a
situation?

> Only in the simplest of cases one should use the basic asserts, anything
> beyond that would benefit from a framework (or like the OP, when you have
> resource constraints maybe)

  Again, I keep asking ... what do these give me?  What benefit?  So far, it
seems to be a large amount of overhead for little gain.

> Sorry Sean, usually read your posts with interest, but this time you made
> me laugh.

  -spc (Glad I could entertain you)

[1] Points awarded to correctly identifying the four other langauges I
        just referenced.

[2] https://www.lua.org/bugs.html#5.1.4-6

[3] I later came to not really like the reverse Polish notation and
        stack gyrations, which is why I don't use it.

[4] A Unix shell.  As a group project, not only did it have to run Unix
        commands, support redirection and environment variable substitution,
        but support simple programming constructs like loops and
        non-environment variables.  I was able to finish the group project
        in a few hours.  Got an A on the project.

[5] Concise Binary Object Representation (RFC-7049)

[6] https://github.com/spc476/CBOR

[7] https://github.com/spc476/CBOR/blob/master/test.lua

Reply | Threaded
Open this post in threaded view
|

Re: BDD testing framework without dependencies

Coda Highland
On Tue, Aug 23, 2016 at 9:43 AM, Sean Conner <[hidden email]> wrote:
>   And I'm *still* puzzled at what a testing framework *buys* you.

The comparison to logging is actually fairly apt.

For the simple cases, you don't need a fancy logger, just like you
don't need a fancy test runner.

But there comes a time when you want to run just one test out of your
whole suite, or when you want to be able to have your test suite
continue running after one test has failed, or when you want to be
able to format your test output in a useful way, or when you want to
improve your test isolation, or when you want to dummy in some
components that can't be autotested hermetically, or when you want to
monitor performance regressions, or when you want to collect
statistics... Well, sure, most of these can be written yourself, but
the biggest advantage of using an existing test framework, especially
a lean, mature one, is that you gain the benefits of the test
framework's development history.

In that sense, it's just like a library. The core reason to use it is
saving time and improving correctness. You're not spending your time
writing the code yourself, and it's less likely to have bugs in it (by
virtue of someone else having already iterated over it a lot) than
stuff you hack up for yourself.

/s/ Adam

Reply | Threaded
Open this post in threaded view
|

Re: BDD testing framework without dependencies

steve donovan
On Tue, Aug 23, 2016 at 7:13 PM, Coda Highland <[hidden email]> wrote:
> But there comes a time when you want to run just one test out of your
> whole suite, or when you want to be able to have your test suite
> continue running after one test has failed, or when you want to be
> able to format your test output in a useful way, or when you want to
> improve your test isolation, or when you want to dummy in some
> components that can't be autotested hermetically, or when you want to
> monitor performance regressions, or when you want to collect
> statistics

I suppose (like Sean) I don't appear to want these ;)  Look, I'm not
knocking the idea but I like tests simple - they don't talk, unless
they break. If they break I sort it out immediately. I don't gain any
satisfaction in seeing pages of pretty green output with the
occasional outbreak of red. The statistics which are ultimately
meaningful are about _coverage_ and that's outside the scope of a test
framework.

Reply | Threaded
Open this post in threaded view
|

Re: BDD testing framework without dependencies

Peter Aronoff
steve donovan <[hidden email]> wrote:
> I suppose (like Sean) I don't appear to want these ;)  Look, I'm not
> knocking the idea but I like tests simple - they don't talk, unless they
> break. If they break I sort it out immediately. I don't gain any
> satisfaction in seeing pages of pretty green output with the occasional
> outbreak of red. The statistics which are ultimately meaningful are about
> _coverage_ and that's outside the scope of a test framework.

You don’t have to want these things. (You also don’t have to want your
tests run in a randomized order, which some test frameworks now do to help
increase test isolation.) But not wanting something or writing your own
minimal library is very different from saying “I don’t know why these
exist.” That seems either disingenuous or silly, and Adam’s example shows
why.

Imagine someone says, “I don’t understand why people write logging modules
since the print function already exists.” In all likelihood, the person
knows perfectly well *why* people write logging modules. The person just
wants an opportunity to say how much smarter they are than everyone else or
to judge everyone else’s work, etc. It’s not a good look.

P
--
We have not been faced with the need to satisfy someone else's
requirements, and for this freedom we are grateful.
    Dennis Ritchie and Ken Thompson, The UNIX Time-Sharing System

Reply | Threaded
Open this post in threaded view
|

Re: BDD testing framework without dependencies

steve donovan
On Tue, Aug 23, 2016 at 7:44 PM, Peter Aronoff <[hidden email]> wrote:
> increase test isolation.) But not wanting something or writing your own
> minimal library is very different from saying “I don’t know why these
> exist.” That seems either disingenuous or silly, and Adam’s example shows
> why.

Well, I don't wish to come across as particularly clever - obviously
test frameworks must be important otherwise there would not be so many
of them. And naturally my workflow will be different. from others and
so forth. Basically just throwing in my 5c here; I understand Sean's
puzzlement, but to express these sentiments is not knocking
frameworks, just saying, we prefer it simple. (I will resist the
temptation to go on about logging framework....)

Reply | Threaded
Open this post in threaded view
|

Re: BDD testing framework without dependencies

Coda Highland
In reply to this post by steve donovan
On Tue, Aug 23, 2016 at 10:33 AM, steve donovan
<[hidden email]> wrote:

> On Tue, Aug 23, 2016 at 7:13 PM, Coda Highland <[hidden email]> wrote:
>> But there comes a time when you want to run just one test out of your
>> whole suite, or when you want to be able to have your test suite
>> continue running after one test has failed, or when you want to be
>> able to format your test output in a useful way, or when you want to
>> improve your test isolation, or when you want to dummy in some
>> components that can't be autotested hermetically, or when you want to
>> monitor performance regressions, or when you want to collect
>> statistics
>
> I suppose (like Sean) I don't appear to want these ;)  Look, I'm not
> knocking the idea but I like tests simple - they don't talk, unless
> they break. If they break I sort it out immediately. I don't gain any
> satisfaction in seeing pages of pretty green output with the
> occasional outbreak of red. The statistics which are ultimately
> meaningful are about _coverage_ and that's outside the scope of a test
> framework.

There are statistics beyond coverage statistics. :P Especially in
large multi-developer projects, it's really useful to have historical
information about which tests fail most often, especially if your test
framework allows automatically retrying failed tests a couple times,
which can illustrate that the code under test (or the test itself)
isn't deterministic.

Like Peter said: Not everyone needs all of these features. If you're
working alone or in a small, tightly-knit group, or if your project is
structurally simple enough that it's easy to keep things deterministic
and hermetic (among other things, this means your project never uses
the network) and well-organized, then you can get away without this
functionality. But as projects and groups grow, the importance of
these things grows simply because of their collaborative benefit.

That said, compiler authors spent years working on being able to
proceed past the first error so that you can get more useful
information at a time instead of iterating over potentially lengthy
operations one bump at a time. Any project of significant size can
benefit from having a test framework that catches errors and
assertions, reports on them, and moves on to the next test.

(On the other hand, I certainly agree that green and red status
indicators are mostly vanity.)

/s/ Adam

Reply | Threaded
Open this post in threaded view
|

Re: BDD testing framework without dependencies

Sean Conner
In reply to this post by Peter Aronoff
It was thus said that the Great Peter Aronoff once stated:

> steve donovan <[hidden email]> wrote:
> > I suppose (like Sean) I don't appear to want these ;)  Look, I'm not
> > knocking the idea but I like tests simple - they don't talk, unless they
> > break. If they break I sort it out immediately. I don't gain any
> > satisfaction in seeing pages of pretty green output with the occasional
> > outbreak of red. The statistics which are ultimately meaningful are about
> > _coverage_ and that's outside the scope of a test framework.
>
> You don’t have to want these things. (You also don’t have to want your
> tests run in a randomized order, which some test frameworks now do to help
> increase test isolation.) But not wanting something or writing your own
> minimal library is very different from saying “I don’t know why these
> exist.” That seems either disingenuous or silly, and Adam’s example shows
> why.

  I did not feel my question was disingenious or silly, as I *really* did
not know why* anyone even bothers with testing frameworks.  While Alexey
provided *an* answer (well, four really), they didn't explain to me *why* a
framework is needed, as the four items he mentioned could be done without a
framework.  It is indeed, Adam's answer that provides, to me, some cases I
did not consider at all (like the randomized order case---question: does
*any* Lua testing framework provide *that* functionality?) [1].

  Just because *you* know does not mean *everybody* knows.

> Imagine someone says, “I don’t understand why people write logging modules
> since the print function already exists.” In all likelihood, the person
> knows perfectly well *why* people write logging modules. The person just
> wants an opportunity to say how much smarter they are than everyone else or
> to judge everyone else’s work, etc. It’s not a good look.

  Or the person has never worked in an environment with centralized logging
for diagnosis or audits.  

  -spc (Or sometimes, you know, the Emperor has no clothes ... )

[1] I was so intrigued with running the tests in a random order that I
        took five minutes to test that with our regression test at work
        (test written in Lua, testing a component written in Lua).  Glad to
        say the tests passed.

        And no, I do not use an existing test framework for this [2].

[2] Even though I need to create 10,660 files before running the 7,776
        tests, and to run the 7,776 tests requires running four other
        programs (in addition to the program being tested and the test
        program---and of the four additional programs, three are mock
        versions of the real thing).

        To be fair, I have a program that generates the 10,660 files
        required for the test, and a separate program that runs everything,
        including the tests.  Yes, you can even run a single test if need
        be.





Reply | Threaded
Open this post in threaded view
|

Re: BDD testing framework without dependencies

Andrew Starks-2
In reply to this post by Coda Highland
Replying to the thread thus far...

I think that the lasting value of testing frameworks (and logging
frameworks) is the standardized inputs and outputs (a protocol?) that
get defined when one of them becomes popular. At that point, anyone's
adhoc tests can be made to integrate into someone else's automated
build environment, without adopting pages of extra framework weight
when you just don't want to do that (for reasons good or bad).


--
Andrew Starks

12