headers
bcr19374 | 1 Jan 2003 04:36
Picon
Favicon

Re: Further TDD Help: Big Changes

--- In testdrivendevelopment <at> yahoogroups.com, "Laurent Bossavit 
<laurent <at> b...>" <laurent <at> b...> wrote:
> Whether the replies on that other thread help you or not, I'd like 
to 
> know more about your situation. Can we look at the tests that are 
> breaking together, to see what they have in common ? How are the 
> tests breaking ?

Here's a typical method that broke:

private JPanel createGangPanel(Sector sector)
{
    JPanel panel = new JPanel();
    panel.setLayout(new BoxLayout(panel, BoxLayout.Y_AXIS));

    panel.add(new JLabel("Gangs"));

    if(sector.getGang() != null) //***
    {
        gangButton_ = new JButton(sector.getGang().getName()); //***
        gangButton_.setActionCommand("gang");
        gangButton_.addActionListener(new GangButtonHandler());
        panel.add(gangButton_);
    }

    return panel;
}

The starred lines are the ones that would break.  Initially, the 
Sector class had a Gang member that you could get with the getGang()
(Continue reading)

Permalink | Reply | 0 comments |
headers
Laurent Bossavit | 1 Jan 2003 10:43

Re: Re: Further TDD Help: Big Changes

> places I could make a Sector.hasGangs() method the initially checks 
> null and once the change to the list is made checks the isEmpty() of 
> that.  But I didn't have the foresight to do that.

So you know more today than you did yesterday. Good news about today, 
as Ron might say, not bad news about yesterday. What does the method 
look like now that it's been refactored to take care of the smells 
you found ?

> In this case fixing it wasn't too bad.  I just had to fix all the 
> compilation errors and had it working in about five or ten minutes.  

Yes. Earlier you mentioned "tests breaking", though, and I'm not sure 
I would describe compile-time errors as "tests breaking". Maybe I'm 
missing something.

So anyway, you made changes in several places in the program, and in 
the tests as well, immediately after having made the change in the 
getGang() interface, right ?

I think that in such a situation I would have wanted to keep the 
original interface in place, but adapted it to the new semantics. 
Suppose you started with

  private Gang myGang;
  public Gang getGang() { return myGang; }

and then introduced a new unit test that used getGang(int) to verify 
the capability to hold multiple gangs; you could end up with
(Continue reading)

Permalink | Reply | 1 comment |
headers
bcr19374 | 1 Jan 2003 15:39
Picon
Favicon

Re: Further TDD Help: Big Changes

--- In testdrivendevelopment <at> yahoogroups.com, "Laurent Bossavit" 
<laurent <at> b...> wrote:
> So you know more today than you did yesterday. Good news about 
today, 
> as Ron might say, not bad news about yesterday. What does the 
method 
> look like now that it's been refactored to take care of the smells 
> you found ?

The second version I posted yesterday is what's currently in the 
code.  I hadn't actually thought the the hasGangs() method until I 
was typing that message.

> > In this case fixing it wasn't too bad.  I just had to fix all the 
> > compilation errors and had it working in about five or ten 
minutes.  
> 
> Yes. Earlier you mentioned "tests breaking", though, and I'm not 
sure 
> I would describe compile-time errors as "tests breaking". Maybe I'm 
> missing something.

Well, the lines where methods were called on the return of the getGang
() function broke compilation because it now returned a LinkedList 
rather than a gang.  The lines that checked the return of getGang() 
against null did not break compilation because it's just as valid to 
check a LinkedList for null.  That resulted in a minute of broken 
tests and head scratching until I realized what was going on.

> So anyway, you made changes in several places in the program, and
(Continue reading)

Permalink | Reply | 0 comments |
headers
Charles Medcoff | 2 Jan 2003 23:54
Picon

Re: TDD and databases

Reading through most of this thread and summurizing one can almost 
conclude that if you have a (web) application that does little more 
than provide a user interface and peform CRUD operations then TDD has 
limited benefit or at least that TDD will cost quite a bit.

Am I wrong?  Comments?

------------------------ Yahoo! Groups Sponsor ---------------------~-->
Flexible Keyboard is the ideal accessory for PDA users that are on the move.
http://us.click.yahoo.com/dCBVZC/WnCFAA/xGHJAA/NhFolB/TM
---------------------------------------------------------------------~->

To unsubscribe from this group, send an email to:
testdrivendevelopment-unsubscribe <at> yahoogroups.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Permalink | Reply | 3 comments |
headers
Griffin Caprio | 3 Jan 2003 00:20
Picon
Favicon

Re: Re: TDD and databases

I think that's about 50% true/ 50% false.  

You can accomplish qua lotalot in the lower layers of
your application with the xUnit testing framework.

However, vanilla assertTrue()'s will only get you so
far.  Once you start to get into testing objects that
rely on other objects, you will need a more complex
add-onng addon to the automation that xUnit provides.

One conceptcontinuouslytinously paid off are Mock
Objects.  Mock Objects are akin fake implementations
of objects, where you control the internals of the
Mock Object.  More than just stubs, you can actually
set expectations on Mock Objects, run your code, then
tell the Mock Object to verify it's own state.  For
example:

public void test() {
   mockConnection.SetExpectedCreateCalls(1);
   mockConnection.SetExpectedCloseCalls(1);
   mockCommand.SetExpectedExecuteCalls(1);
   mockConnection.SetupCommand(mockCommand);

   dbLayer.addUser(mockConnection);

   mockConnection.verify();
   mockCommand.verify();
}
(Continue reading)

Permalink | Reply | 0 comments |
headers
Griffin Caprio | 3 Jan 2003 00:23
Picon
Favicon

Re: Re: TDD and databases - Please excuse the last reply

Please excuse the last reply, my spell checker went
nuts.

I think that's about 50% true/ 50% false.  

You can accomplish quite a lot in the lower layers of
your application with the xUnit testing framework.

However, vanilla assertTrue()'s will only get you so
far.  Once you start to get into testing objects that
rely on other objects, you will need a more complex
add-onng addon to the automation that xUnit provides.

One concept that has paid off are Mock
Objects.  Mock Objects are akin fake implementations
of objects, where you control the internals of the
Mock Object.  More than just stubs, you can actually
set expectations on Mock Objects, run your code, then
tell the Mock Object to verify it's own state.  For
example:

public void test() {
   mockConnection.SetExpectedCreateCalls(1);
   mockConnection.SetExpectedCloseCalls(1);
   mockCommand.SetExpectedExecuteCalls(1);
   mockConnection.SetupCommand(mockCommand);

   dbLayer.addUser(mockConnection);

   mockConnection.verify();
(Continue reading)

Permalink | Reply | 0 comments |
headers
Bill de hÓra | 3 Jan 2003 04:29
Favicon

Re: Re: TDD and databases

Charles Medcoff  wrote:
> Reading through most of this thread and summurizing one can almost 
> conclude that if you have a (web) application that does little more 
> than provide a user interface and peform CRUD operations then TDD has 
> limited benefit or at least that TDD will cost quite a bit.
> 
> Am I wrong?  Comments?

Well, aside from the fact that web is the ultimate expression of 
CRUD... yes and no.

Yes because like it or not testing web (esp HTML) interfaces 
requires a good bit more than the simplest thing that could possibly 
work; it requires tools, maybe even frameworks to automate web 
interface testing. I suspect the future of testing GUIs in general 
lies with XML/XHTML and assertions about the content based on XPaths.

No because, a web application, if it's well designed is just a state 
machine (hypertext 101). This holds however complex the application. 
State machines are in principle easy to test and reason about. 
Still, it's a good amount of work to do it and you really have to 
think about designing for testing from the get go and figure this 
into estimates for a project; it will eat time.  In particular see 
the way XP red book avoided testing servlet output; try to imagine 
if they could have delivered on time by testing the output.

For now the thing to do if you don't describe your interface in XML 
or some machine processable syntax, is test the state of the model 
and resources that backs up that interface and avoid going through 
the browser altogether. Leave look and feel to acceptance tests or
(Continue reading)

Permalink | Reply | 0 comments |
headers
darach_ennis | 3 Jan 2003 06:38
Favicon

Re: TDD and encapsulation / TDD and programming by contract

Hullo all.

Brief delurk from hell...

> 
> >>They are nearly perfect contract specifications.
> 
> > No, this is wrong for a simple practical reason: tests
> > can't say anything about universals, such as "this 
> > function always returns a positive number," or "this
> > function must not be passed a negative number."
> 
> Do you have a proof of this? Theoretically I agree entirely. In 
practice, less
> so.
> 

I live in a DBC world and have used TDD succesfully in that regard 
almost daily for about 2 years now. Well... 2 years plus I guess 
given its already '03.

I was spiking out a P2P CORBA demo about 18 months ago. This was in 
the middle of intermediate experimentations with TFD (although I had 
clued into TDD somewhat organically at that stage).

Where I didn't apply TDD was whenever a contract was introduced into 
my development environment. Specifically CORBA IDL in this case, but 
other contracts apply equally well to my stage and state of ignorance.

One feature of CORBA IDL is that all regular interfaces assume
(Continue reading)

Permalink | Reply | 6 comments |
headers
C. Keith Ray | 3 Jan 2003 18:10
Picon

FW: off-track XP programming discussion

Some misinformation about XP is on

<http://www.codeguru.com/forum/showthread.php?threadid=222466>

One of the posters states that a C++ class designed "xp-style" could be
unsafe, by not implementing copy-constructor and the assignment operator,
and also not putting in private declarations to prevent the compiler from
generating bad copy-constructor and the assignment operator. The poster then
goes on about communicating "intentions" of the programmer, as if XP doesn't
have that as one of the rules of "simple" code.

1. Runs all the tests.
2. Expresses every idea that we need to express.
3. Says everything OnceAndOnlyOnce.
4. Has no superfluous parts.

I'm not a member of codeguru, and don't want to sign up, so I'm putting this
out here in case anyone is member of codeguru and wants to comment.

(By the way, C++ is the only language I'm aware of where the compiler will
generate code for you that can be unsafe to use, and the programmer has to
manually override the compiler to prevent that code generation.)

------------------------ Yahoo! Groups Sponsor ---------------------~-->
Flexible Keyboard is the ideal accessory for PDA users that are on the move.
http://us.click.yahoo.com/dCBVZC/WnCFAA/xGHJAA/NhFolB/TM
---------------------------------------------------------------------~->

To unsubscribe from this group, send an email to:
testdrivendevelopment-unsubscribe <at> yahoogroups.com
(Continue reading)

Permalink | Reply | 1 comment |
headers
Phlip | 3 Jan 2003 19:51
Favicon

Re: FW: off-track XP programming discussion

From: "C. Keith Ray"

> Some misinformation about XP is on
>
> <http://www.codeguru.com/forum/showthread.php?threadid=222466>
>
> One of the posters states that a C++ class designed "xp-style" could be
> unsafe, by not implementing copy-constructor and the assignment operator,
> and also not putting in private declarations to prevent the compiler from
> generating bad copy-constructor and the assignment operator. The poster
then
> goes on about communicating "intentions" of the programmer, as if XP
doesn't
> have that as one of the rules of "simple" code.

0. Obeys the ground rules and "sane subset" of your language.

> 1. Runs all the tests.
> 2. Expresses every idea that we need to express.
> 3. Says everything OnceAndOnlyOnce.
> 4. Has no superfluous parts.

Gods bless C++ programmers who feel pride in the absurdly high level of
discipline needed to code that f5g language, and who scoff at anyone who
could possibly not be toeing the party line!

> I'm not a member of codeguru, and don't want to sign up, so I'm putting
this
> out here in case anyone is member of codeguru and wants to comment.
(Continue reading)

Permalink | Reply | 0 comments |

Gmane