rhydiant | 5 Jan 04:58 2010
Picon

Unit testing

Harking back to my uni days, I recall unit tests being described in terms of specifying pre/post conditions
and class invariants, edge cases, error conditions, null checks, boundary conditions,
positive-cases/negative-cases, equivalence partitions ...

I'm not really thinking about these terms when I practice TDD. Instead, when I'm writing a test for unit of
code, I think in object-oriented terms; roles, responsibilities and collaborations, and limit the
scope of the test to satisfy the current scenario I'm implementing.

Is this similar to how you work? At what point in the development process do you think about and write unit
tests of the first kind?

------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/testdrivendevelopment/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/testdrivendevelopment/join
    (Yahoo! ID required)

<*> To change settings via email:
    testdrivendevelopment-digest <at> yahoogroups.com 
    testdrivendevelopment-fullfeatured <at> yahoogroups.com

<*> To unsubscribe from this group, send an email to:
(Continue reading)

David Burstin | 1 Jan 01:51 2010
Picon

Re: reflections on the bowling game

I think he really did mean MVP (model/view/presenter)  (
http://en.wikipedia.org/wiki/Model-view-presenter , split by Martin Fowler
http://martinfowler.com/eaaDev/ModelViewPresenter.html )

On Fri, Jan 1, 2010 at 3:13 AM, showell30 <showell30 <at> yahoo.com> wrote:

>
>
> Hi Gishu. I like the questions that you are asking about TDD. I was waiting
> to respond, because it was targeted at the gurus. Since none of the gurus
> have responded so far, I assume it is only because they are enjoying the
> holiday season. Not only is it the holiday season, but we are coming to the
> end of a decade, and a very important one in the history of software
> development. Although TDD predates 2000, my own use of it has mostly been
> during this decade, and I've found it to be a thoroughly useful technique.
> Even though I do not use it every day, just understanding the core values
> behind TDD has made me a better programmer. Thank you, and happy holidays,
> to everybody who has contributed to the understanding of this valuable
> methodology!
>
> Gishu's questions are posed in light of a phenomenon that I pointed out
> with respect to the bowling game, which is that code under 100 lines often
> does not necessarily reflect the design patterns that serve you better as
> you add more requirements. In particular, computing a bowling score often
> leads to a functional or procedural solution, whereas programming a full-on
> bowling game often leads more to object-oriented solutions.
>
> First of all, it is not necessarily a bad thing to start with one paradigm
> and finish with another. Let's say your tests for just computing the bowling
> score lead you to an implementation that is mostly functional in nature.
(Continue reading)

Donaldson, John (GEO | 5 Jan 09:02 2010
Picon

RE: Unit testing

Rhydiant,

I just watched an InfoQ video of Coplien and Uncle Bob discussing TDD etc. In this video they briefly
discussed this subject. Uncle Bob claimed that TDD-style unit tests were transformable into
Eiffel-style pre-conditions, post-conditions, invariants etc.

John D.

-----Original Message-----
From: testdrivendevelopment <at> yahoogroups.com [mailto:testdrivendevelopment <at> yahoogroups.com] On
Behalf Of rhydiant
Sent: 05 January 2010 04:59
To: testdrivendevelopment <at> yahoogroups.com
Subject: [TDD] Unit testing

Harking back to my uni days, I recall unit tests being described in terms of specifying pre/post conditions
and class invariants, edge cases, error conditions, null checks, boundary conditions,
positive-cases/negative-cases, equivalence partitions ...

I'm not really thinking about these terms when I practice TDD. Instead, when I'm writing a test for unit of
code, I think in object-oriented terms; roles, responsibilities and collaborations, and limit the
scope of the test to satisfy the current scenario I'm implementing.

Is this similar to how you work? At what point in the development process do you think about and write unit
tests of the first kind?

------------------------------------

Yahoo! Groups Links

(Continue reading)

Michael Hill | 5 Jan 18:17 2010

Re: Unit testing

One of the reasons I've pushed for the use of the word 'microtest' is
precisely the fact that 'unit test' has a significant prior meaning.

For more of the case, see
http://anarchycreek.com/2009/05/20/theyre-called-microtests/

<http://anarchycreek.com/2009/05/20/theyre-called-microtests/>Seeya,
Hill

GeePawHill <at> AnarchyCreek.com
Check GeePawHill's blog <http://anarchycreek.com> on coaching and coding!

On Tue, Jan 5, 2010 at 3:02 AM, Donaldson, John (GEO) <
john.m.donaldson <at> hp.com> wrote:

>
>
> Rhydiant,
>
> I just watched an InfoQ video of Coplien and Uncle Bob discussing TDD etc.
> In this video they briefly discussed this subject. Uncle Bob claimed that
> TDD-style unit tests were transformable into Eiffel-style pre-conditions,
> post-conditions, invariants etc.
>
> John D.
>
>
> -----Original Message-----
> From: testdrivendevelopment <at> yahoogroups.com<testdrivendevelopment%40yahoogroups.com>[mailto:
> testdrivendevelopment <at> yahoogroups.com<testdrivendevelopment%40yahoogroups.com>]
(Continue reading)

Charlie Poole | 5 Jan 18:43 2010

RE: Unit testing

Hi Mike,

I like it. I'm signing on! 

Charlie

> -----Original Message-----
> From: testdrivendevelopment <at> yahoogroups.com 
> [mailto:testdrivendevelopment <at> yahoogroups.com] On Behalf Of 
> Michael Hill
> Sent: Tuesday, January 05, 2010 9:17 AM
> To: testdrivendevelopment <at> yahoogroups.com
> Subject: Re: [TDD] Unit testing
> 
> One of the reasons I've pushed for the use of the word 
> 'microtest' is precisely the fact that 'unit test' has a 
> significant prior meaning.
> 
> For more of the case, see
> http://anarchycreek.com/2009/05/20/theyre-called-microtests/
> 
> <http://anarchycreek.com/2009/05/20/theyre-called-microtests/>Seeya,
> Hill
> 
> GeePawHill <at> AnarchyCreek.com
> Check GeePawHill's blog <http://anarchycreek.com> on coaching 
> and coding!
> 
> On Tue, Jan 5, 2010 at 3:02 AM, Donaldson, John (GEO) < 
> john.m.donaldson <at> hp.com> wrote:
(Continue reading)

Chris Morris | 5 Jan 19:18 2010
Picon

Re: Unit testing

I may have skimmed over it, but how do you then define unit test, if the
microtest definition seems to correspond with an XP-er's unit test
definition?

On Tue, Jan 5, 2010 at 11:17 AM, Michael Hill <mike.hill <at> anarchycreek.com>wrote:

> One of the reasons I've pushed for the use of the word 'microtest' is
> precisely the fact that 'unit test' has a significant prior meaning.
>
> For more of the case, see
> http://anarchycreek.com/2009/05/20/theyre-called-microtests/
>
> <http://anarchycreek.com/2009/05/20/theyre-called-microtests/>Seeya,
> Hill
>
> --
Chris
http://clabs.org

[Non-text portions of this message have been removed]

------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/testdrivendevelopment/

<*> Your email settings:
    Individual Email | Traditional
(Continue reading)

Michael Hill | 5 Jan 19:29 2010

Re: Unit testing

The biggest single difference is scope, and the second biggest is
shipping-reality.

Traditionally, unit tests involve much larger units. A typical old-school
example would be a set of unit tests that run against a COM object,
regardless of whether that interface involves a single class or 300 of them.
 Microtests are truly micro, irrespective of packaging.

Traditionally, unit tests -- indeed most tests -- pay very close attention
to testing the exact binary image in the exact binary environment in which
it runs.  Microtests are almost entirely unconcerned with this.  Microtests
take for granted that they only test that object X works the way it's
supposed to  *with  the assumption* that object X's collaborators work the
way they're supposed to.

So you see that although a unit test *could* be a microtest, the word itself
has a prior meaning that confuses experienced test-makers who are XP noobs.

Seeya,
Hill

Check GeePawHill's Blog <http://anarchycreek.com> on Coaching and Coding

On Tue, Jan 5, 2010 at 1:18 PM, Chris Morris <the.chrismo <at> gmail.com> wrote:

>
>
> I may have skimmed over it, but how do you then define unit test, if the
> microtest definition seems to correspond with an XP-er's unit test
> definition?
(Continue reading)

Chris Morris | 5 Jan 19:33 2010
Picon

Re: Unit testing

Looks like we have another wrinkle for Mr. Feathers:
http://blog.objectmentor.com/articles/2009/04/13/x-tests-are-not-x-tests

On Tue, Jan 5, 2010 at 12:29 PM, Michael Hill <mike.hill <at> anarchycreek.com>wrote:

> The biggest single difference is scope, and the second biggest is
> shipping-reality.
>
> Traditionally, unit tests involve much larger units. A typical old-school
> example would be a set of unit tests that run against a COM object,
> regardless of whether that interface involves a single class or 300 of
> them.
>  Microtests are truly micro, irrespective of packaging.
>
> Traditionally, unit tests -- indeed most tests -- pay very close attention
> to testing the exact binary image in the exact binary environment in which
> it runs.  Microtests are almost entirely unconcerned with this.  Microtests
> take for granted that they only test that object X works the way it's
> supposed to  *with  the assumption* that object X's collaborators work the
> way they're supposed to.
>
> So you see that although a unit test *could* be a microtest, the word
> itself
> has a prior meaning that confuses experienced test-makers who are XP noobs.
>
> Seeya,
> Hill
>
> --
Chris
(Continue reading)

Steve Howell | 5 Jan 19:41 2010
Picon

Re: Unit testing

I really like the "microtest" terminology.  It seems like "unit test" is indeed overloaded.

After using "microtest," I guess the next steps would be to have some way to refer to the collection of
microtests that all apply to the same method and/or class, and then also to have some notion of a
"millitest," which is a test that is slightly more complex than a microtest.  Maybe "millitests" are not
needed at all for some applications, but having the terminology might be helpful to explain when and when
not to use them.

________________________________
From: Michael Hill <mike.hill <at> anarchycreek.com>
To: testdrivendevelopment <at> yahoogroups.com
Sent: Tue, January 5, 2010 10:29:43 AM
Subject: Re: [TDD] Unit testing

The biggest single difference is scope, and the second biggest is
shipping-reality.

Traditionally, unit tests involve much larger units. A typical old-school
example would be a set of unit tests that run against a COM object,
regardless of whether that interface involves a single class or 300 of them.
Microtests are truly micro, irrespective of packaging.

Traditionally, unit tests -- indeed most tests -- pay very close attention
to testing the exact binary image in the exact binary environment in which
it runs.  Microtests are almost entirely unconcerned with this.  Microtests
take for granted that they only test that object X works the way it's
supposed to  *with  the assumption* that object X's collaborators work the
way they're supposed to.

So you see that although a unit test *could* be a microtest, the word itself
(Continue reading)

Chet Hendrickson | 5 Jan 21:31 2010

Re: Unit testing

Hello Steve,

I have always found the term 'unit test' to be so overloaded as to be
useless.  Back in the Pink Book, we decided to drop that term as well
as 'acceptence test' in order to avoid these sorts of discussions.

We started using 'developer test' and 'customer test' as a way to
indicate the purpose of the test as opposed to some other attribute.
Today, and I hope this has been consistant over time, I define
'developer tests' as tests owned and written by developers to prove to
themselves and their colleagues that the code they wrote does what
they want it to do.  It explains the codes usage and protects it
during future changes.

'Customer Tests' are tests owned by the Customer, although they may be
written and maintained by others, that prove to the Customer that the
code under test implements the feature(s) that they have asked for.
They define a contract between the Customer and the developers, such
that when the tests successfully execute, the story requesting the
feature is done.

chet

Tuesday, January 5, 2010, 1:41:04 PM, you wrote:

> I really like the "microtest" terminology.  It seems like "unit test" is indeed overloaded.

> After using "microtest," I guess the next steps would be to have
> some way to refer to the collection of microtests that all apply to
> the same method and/or class, and then also to have some notion of a
(Continue reading)


Gmane