headers
Ron Jeffries | 1 Oct 2010 01:19
Picon
Favicon
Gravatar

Re: Re: Does a focus on unit tests lead to violating YAGNI?

Hello, Stan.  On Thursday, September 30, 2010, at 5:59:17 PM, you
wrote:

> Taking what you said, we can add to it to get another contradiction:

>           Never write code without a failing test
>           Never write a test without failing code

No one actually says that, as far as I know.

One writes tests for at least three reasons:

One reason is because some capability does not exist, so we write a
test that shows that, and that we use to determine when we're done
implementing it. That's TDD.

One also writes tests when one thinks that the code works but one is
not as sure as one would like to be. Here, we're just beefing up the
tests that protect us when we refactor. We don't /expect/ to find a
bug, but sometimes we do.

And one writes tests when a bug has been found, to isolate it and
show when it is fixed. This is the "with failing code" case, I
suppose.

> When I first tried to write test-first, I had a big problem,
> because I prided myself on having one test case per domain class,
> and one test method per domain method - except for accessors, of
> course :).  So I had to do "design" before I wrote any tests.  Yucky....
(Continue reading)

Permalink | Reply | 8 comments |
headers
Curtis Cooley | 1 Oct 2010 01:19
Picon

Re: Re: Does a focus on unit tests lead to violating YAGNI?

On Thu, Sep 30, 2010 at 2:17 PM, Ron Jeffries <ronjeffries <at> acm.org> wrote:
> Hello, Stan.  On Thursday, September 30, 2010, at 4:18:43 PM, you
> wrote:
>
>> Maybe we can tweak the "test first" rule?  What about:
>
>> I can only write a "test first" test if it tests a user story, or
>> tests a missing method in another test.  I.E. I cannot write a
>> test for a method that is not called from somewhere.
>
> Yes. That's what works best. At UNL when we were teaching our
> CSM+ASD course there, this question came up and we didn't pick up on
> quite what was going on. A number of the students did TDD, but
> mostly what they did was TDD all the accessors for classes they
> thought they needed.
>
> I riffed for a while on the fact that I never write tests for
> accessors, and someone said that they thought that was a
> contradiction to never writing a line of code without a failing
> test.
>
> Once I figured out what I should have said in the moment, I wrote
> this:
>
> Contradiction: Test Everything, but not Accessors?
>
>  At the Agile Developer Skills course at the Raikes School, I
>  commented that we don’t usually test accessors. But we test
>  everything. Is this a contradiction?
>
(Continue reading)

Permalink | Reply | 1 comment |
headers
David H | 1 Oct 2010 01:34
Picon
Gravatar

Re: This could be fun. I hope.

On 10-09-23 1:18 AM, George Dinwiddie wrote:
> Esther,
>
> On 9/22/10 7:03 PM, Esther Schindler wrote:
>> George my dear, I am always happy to quote you in my articles,
>> because you always make me look smarter. :-)
>
> I hardly think so, because you look pretty smart already.
>
>> I agree with your overall assessment but I'm scratching my head to
>> come up with an example. Can we imagine a scenario?
>
> OK, what about this hypothetical scenario:  A system admin is going on a
> business trip in a few weeks, and wants the web interface that he often
> uses customized in a version more usable on a cell phone browser rather
> than having to use the company laptop.
>
> For an experienced Agile team, this is just another change, even if
> they've never done a cell phone interface before.  The code is already
> well factored such that putting a new front end is fairly
> straightforward; they just need to learns the ins and outs of what
> displays well on the small screen.

Having been in that situation myself (as the sys admin) I would never 
allow the deveolpment team to fuck around with an interface that 
monitors a live system just to make it prettier on my cell phone. I 
would rather get myself a better cellphone, such as an iPhone where I 
can have a half decent, fully featured browser. The one thing you do not 
do when you are a system adinsitrator is fuck around with a system that 
is up and running well just because you want a prettier interface to
(Continue reading)

Permalink | Reply | 1 comment |
headers
JeffGrigg | 1 Oct 2010 02:27
Picon
Gravatar

Re: Does a focus on unit tests lead to violating YAGNI?

--- "Stan" <stasil213 <at> ...> wrote:
> I finally made some progress when I stated naming my initial
> test "test" (took a long time to figure this one out).  [...]

I've been doing that for some time.  I got into it when pair programming, when some of my pair partners seemed
to be discussing obsessing over the proper name for a test method -- when we haven't even figured out what
it's going to test yet.  So I just start...

  public void test() {
    fail("Hi mom!");
  }

I run it.  It fails.  Now I know that I wrote the test method correctly.

Going on...

OK, I think I want to score a bowling game.  I guess I'll create one of those:

  public void test() {
    BowlingGame game = new BowlingGame();
  }

It doesn't compile, so I create the class.  And I go on from there, until the test is done and it passes:

  public void test() {
    BowlingGame game = new BowlingGame();
    assertEquals(0, game.score(new int[] {0,0, 0,0, 0,0, 0,0, 0,0, 0,0, 0,0, 0,0, 0,0, 0,0};
  }

OK.  So then I ask myself...
(Continue reading)

Permalink | Reply | 2 comments |
headers
JeffGrigg | 1 Oct 2010 02:33
Picon
Gravatar

Re: Does a focus on unit tests lead to violating YAGNI?

--- Curtis Cooley <curtis.cooley <at> ...> wrote:
> I've always like "Test everything that could possibly break,"
> but that also implies you are at a level where "everything
> that could possibly break" obviously does not include accessors.

I did test all the getters and setters on a project once.  (My team members were not on-board with the TDD
thing.)  And the Rational Rose CASE tool was making a habit out of deleting the bodies of methods.

So I wrote a test that used reflection to find all the getters and setters on all classes, and for those types
it understood, call each with a sequence of values, to make sure they worked correctly.  I found and fixed a
bunch of getters and setters that way.

(Having the bodies of bigger methods get deleted was usually more obvious, even during casual testing. 
Having the body of a setter deleted was kind of hard to detect and rather difficult to debug, without good tests!)
Permalink | Reply | 0 comments |
headers
Dave Rooney | 1 Oct 2010 04:00
Picon
Favicon

Re: Re: Does a focus on unit tests lead to violating YAGNI?

  On 30/09/2010 8:27 PM, JeffGrigg wrote:
> I got into it when pair programming, when some of my pair partners seemed to be discussing obsessing over
the proper name for a test method

A buddy of mine deals with that issue in a very elegant way.

"If you can't name it within 5 seconds, call it 'Duck' and move on.  The 
right name will come to you later."

You may substitute whatever you like for 'Duck'... I typically use 
'Xyzzy'. ;)
--

-- 
Dave Rooney
Westboro Systems
Web: http://www.WestboroSystems.com
Blog: http://practicalagility.blogspot.com
Twitter: daverooneyca
Permalink | Reply | 1 comment |
headers
Charlie Poole | 1 Oct 2010 08:25
Favicon

Re: Does a focus on unit tests lead to violating YAGNI?

What kind of objects are you putting into it? What is the purpose of
storing those
objects? Name it accordingly.

Charlie

On Mon, Sep 27, 2010 at 7:26 AM, JeffGrigg <jeffreytoddgrigg <at> gmail.com> wrote:
>> --- JeffGrigg wrote:
>>> But other programmers would think it silly if I built a Stack with no 'isEmpty()' method, so I'll write a
test for that, and add the method.
>
> --- Dave Rooney <dave.rooney <at> ...> wrote:
>> Don't call it a stack... call it (with the help of thesaurus.com) an
>> Accumulation, Aggregation, Amassment, Assemblage, Assortment, Bank,
>> Barrel, Buildup, Chunk, Conglomeration, Drift, Gob, Hill, Hoard, Hunk,
>> Jumble, Lump, Mass, Mound, Mountain, Much, Ocean, Oodles, Pack, Peck,
>> Pyramid, Quantity, Shock...
>>
>> Semi-seriously.
>>
>> If the name 'stack' implies behaviour that you don't need,
>> don't call it a stack.
>
> So which of those names do you think best matches a kind of container where I put objects into it, and get
objects out of it, and whenever I get an object out, I should get the one that I most recently put in (and have
it removed from the collection).  And in this case, it never needs to hold more than ten objects.
>
> I assert that no matter what word I use, the word is likely to suggest some meaning and usage beyond what I
happen to need it to do right now.
>
(Continue reading)

Permalink | Reply | 1 comment |
headers
Clive Evans | 1 Oct 2010 10:53

Re: This could be fun. I hope.


On 1 Oct 2010, at 00:34, David H wrote:
> Having been in that situation myself (as the sys admin) I would never
> allow the deveolpment team to fuck around with an interface that
> monitors a live system just to make it prettier on my cell phone. I
> would rather get myself a better cellphone, such as an iPhone where I
> can have a half decent, fully featured browser. The one thing you do  
> not
> do when you are a system adinsitrator is fuck around with a system  
> that
> is up and running well just because you want a prettier interface to
> access it. You would usually try it out on a backup system or a system
> that monitors machines which are not in live use. After that has  
> worked
> for a while you _might_ transiiton it into the real environment.
>
>

Having become a developer after spending a lot of time as a System  
Administrator tweaking my control interfaces almost constantly, I'd  
suggest that while you may be playing safe, in actuality you're  
missing out on an opportunity to learn more about running your systems  
and improve your reliability steadily.

Prettier is very important in control systems, as is usability. Being  
Pretty and usable on devices such as a mobile phone is one of the best  
things you can aspire to - it takes your time to respond to an  
incident to almost nothing, regardless of where you are and whether  
you are on technically duty or not.
(Continue reading)

Permalink | Reply | 0 comments |
headers
JeffGrigg | 1 Oct 2010 11:08
Picon
Gravatar

Re: Does a focus on unit tests lead to violating YAGNI?

> --- JeffGrigg wrote:
>> [When some of my] pair programming [...] partners seemed to
>> be obsessing over the proper name for a test method...

--- Dave Rooney <dave.rooney <at> ...> wrote:
> A buddy of mine deals with that issue in a very elegant way.
> "If you can't name it within 5 seconds, call it 'Duck' and
>  move on.  The right name will come to you later."

I have that pattern.  ;->

When my pair partner starts obsessing over what to call a class or method or variable that we're about to
create, I wait for a moment, and then I just name it the first thing that comes to my mind, and move on.  Like
"PoorlyNamedClass" or "int someKindOfImportantValue = 16;"  I try to come up with a name that
sufficiently annoying that we won't want to check it in.  >;->
Permalink | Reply | 0 comments |
headers
MarvinToll.com | 1 Oct 2010 11:50

Re: Does a focus on unit tests lead to violating YAGNI?

If you are going to test accessor methods you may want to consider using TestUtil.

http://gtcgroup.com/testutil.html

--- In extremeprogramming <at> yahoogroups.com, Ron Jeffries <ronjeffries <at> ...> wrote:
>
> Hello, Stan.  On Thursday, September 30, 2010, at 4:18:43 PM, you
> wrote:
> 
> > Maybe we can tweak the "test first" rule?  What about:
> 
> > I can only write a "test first" test if it tests a user story, or
> > tests a missing method in another test.  I.E. I cannot write a
> > test for a method that is not called from somewhere.
> 
> Yes. That's what works best. At UNL when we were teaching our
> CSM+ASD course there, this question came up and we didn't pick up on
> quite what was going on. A number of the students did TDD, but
> mostly what they did was TDD all the accessors for classes they
> thought they needed.
> 
> I riffed for a while on the fact that I never write tests for
> accessors, and someone said that they thought that was a
> contradiction to never writing a line of code without a failing
> test.
> 
> Once I figured out what I should have said in the moment, I wrote
> this:
> 
> Contradiction: Test Everything, but not Accessors?
(Continue reading)

Permalink | Reply | 17 comments |

Gmane