Discussion of the eXtreme Programming practice of TestDrivenDevelopment

Paul Michali | 3 Aug 2004 13:22

Suggestions on how to approach TDD for this problem?

Hi all!

In my never ending quest to try to learn TDD (and
play in areas where I have little experience), I'm
trying to write a second generation of a small
command line Java app that I made for processing
membership info for a local car club.

PROBLEM DESCRIPTION:

As membership chair, I get, on a monthly basis an
Excel spreadsheet that has a listing of all the
membership. Each entry has member name, address,
phone, e-mail, etc. and most importantly current
status (current, new, expired).

With this information I have two goals. Goal "A"
is to generate various reports of interest to
members. Examples are, number of new members,
expired members, percent and number of members
per county, per state in the region, and total
members in this chapter. List of new members,
with city and car model(s) and year(s), and so
on. this info is presented in the club newsletters
and presented at meetings.

Goal "B" is to maintain a "database" of both
current and old membership information. Unlike
the monthly spreadsheets, I want to keep information
on expired members, so that I can evaluate historical

(Continue reading)

headers

J. B. Rainsberger | 8 Aug 2004 13:46

Re: Suggestions on how to approach TDD for this problem?

I know I'm behind my time, but....

Paul Michali wrote:

> I'm having trouble figuring out how to get started
> with TDD. My first story is one that reads the spreadsheet
> and writes to a SQL database to effectively "import" the
> new month info. I'm starting with the first part, "read
> the data from the spreadsheet". Can anyone advise on how
> I approach this test-first?

Hm. Simpler, perhaps: what about opening the spreadsheet as an ODBC data 
source and just performing SQL queries against it? Have you tried this 
before? I have, with decent results.

> Is that the simplest thing that could work? It just feels
> like a functional test and not a unit test to me and it
> seems like I have to write a lot of code to get the first
> test to work (I tried and had to write several routines).
> Should I be breaking this into separate tests, like
> connecting to the database, performing a query, checking
> the contents?

You have data coming from source A (Reader interface) and going to 
destination B (Writer interface).

First test-drive the code that uses these interfaces to get the data 
from A to B, which will drive out the required interfaces.

Next, test-drive a WIN32OLE implementation of A and a JDBC

(Continue reading)

headers

Paul Michali | 9 Aug 2004 14:22

Re: Suggestions on how to approach TDD for this problem?

J. B. Rainsberger wrote:

> I know I'm behind my time, but....
> 
> Paul Michali wrote:
> 
> 
>>I'm having trouble figuring out how to get started
>>with TDD. My first story is one that reads the spreadsheet
>>and writes to a SQL database to effectively "import" the
>>new month info. I'm starting with the first part, "read
>>the data from the spreadsheet". Can anyone advise on how
>>I approach this test-first?
> 
> 
> Hm. Simpler, perhaps: what about opening the spreadsheet as an ODBC data 
> source and just performing SQL queries against it? Have you tried this 
> before? I have, with decent results.

The first version of my app did just that, used JDBC/ODBC
and read the spreadsheet as a database. In this second
version I've been entertaining other suggestions and one
was to use POI. I've started doing that, however, I then
questioned that, since I will be writing out the data to
a database, should I read the data as if it was a database.

I guess I'll need to make a call at some point in time
as to whether to switch. Maybe if I do this well, I can
switch from one method to the other?

(Continue reading)

headers

J. B. Rainsberger | 9 Aug 2004 18:50

Re: Suggestions on how to approach TDD for this problem?

Paul Michali wrote:

> I was wondering that. Unfortunately, I'm not versed in VBScript.

Neither am I. It turned out not to be too scary, especially since you 
can record macros and look at the VBScript code afterward.

> Does anyone know how to (in an automated way) convert an Excel
> file to a tab delimited file? 

I got this from Excel 2000:

Sub SaveAsTabDelimited()
'
' SaveAsTabDelimited Macro
' Macro recorded 2004-08-09 by J. B. Rainsberger
'
' Keyboard Shortcut: Ctrl+q
'
     ActiveWorkbook.SaveAs Filename:="D:\home\jbrains\My 
Documents\Book1.txt", FileFormat:=xlText, CreateBackup:=False
End Sub

This saves the current workbook and the active sheet. If your workbook 
has only one sheet--that's very common--then this ought to be enough. 
The result is tab-delimited. As I thought, it's a one-liner.
--

-- 
J. B. Rainsberger,
Diaspar Software Services
http://www.diasparsoftware.com :: +1 416 791-8603

(Continue reading)

headers

Paul Michali | 10 Aug 2004 13:32

Re: Suggestions on how to approach TDD for this problem?

J. B. Rainsberger wrote:
> Paul Michali wrote:
> 
> 
>>I was wondering that. Unfortunately, I'm not versed in VBScript.
> 
> 
> Neither am I. It turned out not to be too scary, especially since you 
> can record macros and look at the VBScript code afterward.
> 
> 
>>Does anyone know how to (in an automated way) convert an Excel
>>file to a tab delimited file? 
> 
> 
> I got this from Excel 2000:
> 
> Sub SaveAsTabDelimited()
> '
> ' SaveAsTabDelimited Macro
> ' Macro recorded 2004-08-09 by J. B. Rainsberger
> '
> ' Keyboard Shortcut: Ctrl+q
> '
>      ActiveWorkbook.SaveAs Filename:="D:\home\jbrains\My 
> Documents\Book1.txt", FileFormat:=xlText, CreateBackup:=False
> End Sub
> 
> This saves the current workbook and the active sheet. If your workbook 
> has only one sheet--that's very common--then this ought to be enough.

(Continue reading)

headers

Paul Michali | 11 Aug 2004 22:37

Re: Suggestions on how to approach TDD for this problem?

Paul Michali wrote:

> J. B. Rainsberger wrote:

>>I got this from Excel 2000:
>>
>>Sub SaveAsTabDelimited()
>>'
>>' SaveAsTabDelimited Macro
>>' Macro recorded 2004-08-09 by J. B. Rainsberger
>>'
>>' Keyboard Shortcut: Ctrl+q
>>'
>>     ActiveWorkbook.SaveAs Filename:="D:\home\jbrains\My 
>>Documents\Book1.txt", FileFormat:=xlText, CreateBackup:=False
>>End Sub
>>
>>This saves the current workbook and the active sheet. If your workbook 
>>has only one sheet--that's very common--then this ought to be enough. 
>>The result is tab-delimited. As I thought, it's a one-liner.
> 
> 
> Awesome! I'll give it a try.

Rather than using a macro I tried to do this with
scripting on my PC, but I'm having some problems.

I have this script, which works, but the resulting
text file has a bunch of extra (junk) in it and
doesn't look like just plain tab delimited text.

(Continue reading)

headers

J. B. Rainsberger | 12 Aug 2004 03:00

Re: Suggestions on how to approach TDD for this problem?

Paul Michali wrote:

> Paul Michali wrote:
> 
> 
>>J. B. Rainsberger wrote:
> 
> 
>>>I got this from Excel 2000:
>>>
>>>Sub SaveAsTabDelimited()
>>>'
>>>' SaveAsTabDelimited Macro
>>>' Macro recorded 2004-08-09 by J. B. Rainsberger
>>>'
>>>' Keyboard Shortcut: Ctrl+q
>>>'
>>>    ActiveWorkbook.SaveAs Filename:="D:\home\jbrains\My 
>>>Documents\Book1.txt", FileFormat:=xlText, CreateBackup:=False
>>>End Sub
>>>
>>>This saves the current workbook and the active sheet. If your workbook 
>>>has only one sheet--that's very common--then this ought to be enough. 
>>>The result is tab-delimited. As I thought, it's a one-liner.
>>
>>
>>Awesome! I'll give it a try.
> 
> 
> Rather than using a macro I tried to do this with

(Continue reading)

headers

Paul Michali | 21 Aug 2004 02:14

Re: Suggestions on how to approach TDD for this problem?

Hey folks! Just a quick update on my progress and a question
on how to TDD a part of this design...

I was able to change to using a DAO pattern and I can read
Member objects from a SpreadsheetDataSource. Next, I made
an abstract superclass and called it MemberDAO and renamed
the one I had as SpreadsheetMemberDAO.

Finally, I created a MySqlMemberDAO that I'll use to write
the Member objects to the database. The thought is that
later I'll put in a factory to select between the two DAOs.

 From the SpreadsheetMemberDAO, I have retrieve() and
retrieveAll() methods to get one or all Members from the
SpreadsheetDataSource. To this, I added a create() method
(and a test class) to test writing out the Member to the
MySQL database.

That's where I'm a bit stuck (for the moment). I'm wonder-
ing how to test writing to the database. Here's the first
test case I made:

public void testCreate() {
     MemberDAO dao = new MySqlMemberDAO();

     Member member = new Member();
     member.setNumber(1234);
     member.setName("Paul Michali");

     assertEquals("Created member",

(Continue reading)

headers

Kaoru Hosokawa | 21 Aug 2004 06:34

Re: Suggestions on how to approach TDD for this problem?

Couldn't answer all your questions, but ...

On 2004/08/21, at 9:14, Paul Michali wrote:

> public void testCreate() {
>      MemberDAO dao = new MySqlMemberDAO();
>
>      Member member = new Member();
>      member.setNumber(1234);
>      member.setName("Paul Michali");
>
>      assertEquals("Created member",
>                   "1234-Paul Michali",
>                   dao.create(member));
> }
>
> Here's the questions I have for the group...
>
> - Is this the most basic test to start with?
>

If the purpose of your test is to check whether the creation of  
MySqlMemberDAO was successful or not, I think the following  test is  
more basic.

public void testCreate() {
	assertNotNull(new MySqlMemberDAO());
}

But I usually skip such tests and start with something more -- similar

(Continue reading)

headers

J. B. Rainsberger | 21 Aug 2004 08:30

Re: Suggestions on how to approach TDD for this problem?


Kaoru Hosokawa wrote:

>>- Is this the most basic test to start with?
> 
> If the purpose of your test is to check whether the creation of  
> MySqlMemberDAO was successful or not, I think the following  test is  
> more basic.
> 
> public void testCreate() {
> 	assertNotNull(new MySqlMemberDAO());
> }

The Java Language Specification proves that this can't fail unless the 
compiler or interpreter is broken. Don't Test the Platform.

>>- Once I've done the create, how do I verify that it
>>   worked right?
> 
> I think your tests does just that. I would change the method name from  
> create to insertMember though. The test would look something like this:
> 
> public void testInsertMember() {
> 	MemberDAO dao = new MySqlMemberDAO();
> 
> 	Member member = new Member();
> 	member.setNumber(1234);
> 	member.setName("Paul Michali");
> 
> 	assertEquals("Inserted Member", "1234-Paul Michali",

(Continue reading)

headers

Paul Michali | 21 Aug 2004 20:43

Re: Suggestions on how to approach TDD for this problem?

J. B. Rainsberger wrote:

> I use a different approach.
> 
> public void testCreateMember() throws Exception {
>      MySqlMemberDAO memberDao = new MySqlMemberDAO();
> 
>      Member paul = Member.create(1234, "Paul Michali");
>      dao.create(paul);
> 
>      // execute query 'select count(*) from member where id=1234'
>      // assert count is 1
> }

I was wondering what your thoughts are about how to uniquely
identify members. The member number is NOT unique. In the
previous version I used the number and member's first and last
name as a primary key.

For this version, I've joined the member name parts into a
single member name field in my Member class. Should I use the
number + name as a key in the database, or use an arbitrary
unique key in the database? In reading "SQL for smarties"
the author seemed to discourage using an internally created
key. I'd just like to hear some thoughts on this from people.

In the above, I'd need to have use the number and name for
the key.

Lastly, I had a question about Member creation. In the TDD

(Continue reading)

headers

J. B. Rainsberger | 23 Aug 2004 03:22

Re: Suggestions on how to approach TDD for this problem?


Paul Michali wrote:

> J. B. Rainsberger wrote:
> 
> 
>>I use a different approach.
>>
>>public void testCreateMember() throws Exception {
>>     MySqlMemberDAO memberDao = new MySqlMemberDAO();
>>
>>     Member paul = Member.create(1234, "Paul Michali");
>>     dao.create(paul);
>>
>>     // execute query 'select count(*) from member where id=1234'
>>     // assert count is 1
>>}
> 
> 
> I was wondering what your thoughts are about how to uniquely
> identify members. The member number is NOT unique. In the
> previous version I used the number and member's first and last
> name as a primary key.

Then change the WHERE clause accordingly.

> For this version, I've joined the member name parts into a
> single member name field in my Member class. Should I use the
> number + name as a key in the database, or use an arbitrary
> unique key in the database? In reading "SQL for smarties"

(Continue reading)

headers

Paul Michali | 23 Aug 2004 14:52

Re: Suggestions on how to approach TDD for this problem?


J. B. Rainsberger wrote:

 > I wrote:
>>Lastly, I had a question about Member creation. In the TDD
>>work I did before, I created an empty Member and then the
>>DAO would call various add() methods to fill out each field
>>of the Member object, using info from the DataSource. For
>>example:
>>
>>private void addId() {
>>     member.setNumber(sheet.getNumberFromTextCell(1));
>>}
>>...
>>private void addJoinDate() {
>>     member.setJoinDate(sheet.getTextDateCell(16));
>>}
>>
>>I'd call dao.retrieve(#) and then check that the Member
>>had the right ID number in one test, name in another,
>>etc. as I fleshed out each part of the Member that was
>>obtained from the Spreadsheet.
>>
>>I never got to a point where I needed a constructor that
>>had all the arguments needed to create a complete Member.
>>
>>Was there something I missed in the TDD process?
> 
> 
> Not necessarily. Somewhere /else/ you may find it convenient to add the

(Continue reading)

headers

J. B. Rainsberger | 23 Aug 2004 23:26

Re: Suggestions on how to approach TDD for this problem?

Paul Michali wrote:

>>>Should I create this constructor to make testing of the
>>>dao.create() capability easier?
>>
>>Does it actually make the testing easier?
> 
> Well, sort of. If I want to have a fully created Member
> object that I then give to dao.create(), then yes, it is
> easier (having a ctor with all the fields versus an empty
> ctor and calling N set functions).

I believe as general practice that:

1. There should be one and only one way to create each object--that is, 
only one constructor.

2. All objects should be sane--that is, an object should not be created 
unless it is given enough data to be valid.

You can draw the same conclusions that I did from these two practices, 
and see how it affects your design.

> For the first go at this, I just created a member with
> only the fields that are used in the "primary key" filled
> out and then called dao.create(member). I guess as I go
> farther with this I'll hit a point where I need to fully
> create the member and then I can create a ctor that takes
> all of the fields.

(Continue reading)

headers

Paul Michali | 24 Aug 2004 20:19

Re: Suggestions on how to approach TDD for this problem?

J. B. Rainsberger wrote:

>>Right now I've hit a small snag in testing of the DAO
>>for SQL. I had created tests for the DataSource and was
>>able to verify that, with a Member that consists only of
>>the "primary key" fields (name, ID#), I can:
>>
>>- create the empty table
>>- insert the "member" entry in the table
>>- insert member into a different table name
>>- find an entry in a table
>>- create in one table, verify not found in another
>>- verify find fails, when key doesn't match
> 
> 
> Do you mean the actual interface javax.sql.DataSource?
No. I mean the MySqlDataSource object that I created
to access the database. In addition to that, I have a
MySqlMemberDAO that is called by the client. In a
similar fashion, I have a SpreadsheetDataSource and
a SpreadsheetMemberDAO to access the Excel spreadsheet.

The former know about how to access the data source
and the latter know about the domain (Member objects).

  Why are you
> testing the platform?

I'm not. It's just hard to express this in e-mail
messages...

(Continue reading)

headers

David Kramer | 24 Aug 2004 07:19

Re: Suggestions on how to approach TDD for this problem?


J. B. Rainsberger wrote, On 08/23/2004 05:26 PM:
> I believe as general practice that:
> 
> 1. There should be one and only one way to create each object--that is, 
> only one constructor.

I personally would broaden this to say that there should be only one 
constructor that does the real construction.  I think it's OK to have other 
constructors with different signatures as long as they in turn call the One 
True Constructor to do the work.

Is that evil?  I see the value in not having multiple constructors with 
similar code in them, for sure.

--

-- 
DDDD   David Kramer         david <at> thekramers.net       http://thekramers.net
DK KD
DKK D  Proud member, AAAAA
DK KD  American Association Against Acronym Abuse
DDDD

------------------------ Yahoo! Groups Sponsor --------------------~--> 
Make a clean sweep of pop-up ads. Yahoo! Companion Toolbar.
Now with Pop-Up Blocker. Get it for free!
http://us.click.yahoo.com/L5YrjA/eSIIAA/yQLSAA/NhFolB/TM
--------------------------------------------------------------------~-> 

 
Yahoo! Groups Links

(Continue reading)

headers

J. B. Rainsberger | 24 Aug 2004 16:55

Re: Suggestions on how to approach TDD for this problem?

David Kramer wrote:

> J. B. Rainsberger wrote, On 08/23/2004 05:26 PM:
> 
>>I believe as general practice that:
>>
>>1. There should be one and only one way to create each object--that is, 
>>only one constructor.
> 
> I personally would broaden this to say that there should be only one 
> constructor that does the real construction.  I think it's OK to have other 
> constructors with different signatures as long as they in turn call the One 
> True Constructor to do the work.
> 
> Is that evil?  I see the value in not having multiple constructors with 
> similar code in them, for sure.

I agree with you, but I have been experimenting with only one 
constructor for each object, and pushing the rest to creation methods. I 
can't say I notice much of a difference, so far.
--

-- 
J. B. Rainsberger,
Diaspar Software Services
http://www.diasparsoftware.com :: +1 416 791-8603
Let's write software that people understand

------------------------ Yahoo! Groups Sponsor --------------------~--> 
Make a clean sweep of pop-up ads. Yahoo! Companion Toolbar.
Now with Pop-Up Blocker. Get it for free!
http://us.click.yahoo.com/L5YrjA/eSIIAA/yQLSAA/NhFolB/TM

(Continue reading)

headers

Russell Gold | 25 Aug 2004 17:11

Re: Suggestions on how to approach TDD for this problem?

On Tue, 24 Aug 2004 10:55:54 -0400, J. B. Rainsberger
<jbrains <at> rogers.com> wrote:
> I agree with you, but I have been experimenting with only one
> constructor for each object, and pushing the rest to creation methods. I
> can't say I notice much of a difference, so far.

You mean static creation methods all calling a single private
constructor and calling setters (possibly private) to add anything
else? Or does your constructor take the superset of initialization
values and rely on the creation methods to supply the appropriate
values?

How do you deal with subclasses?

------------------------ Yahoo! Groups Sponsor --------------------~--> 
Make a clean sweep of pop-up ads. Yahoo! Companion Toolbar.
Now with Pop-Up Blocker. Get it for free!
http://us.click.yahoo.com/L5YrjA/eSIIAA/yQLSAA/NhFolB/TM
--------------------------------------------------------------------~-> 

Yahoo! Groups Links

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

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

<*> Your use of Yahoo! Groups is subject to:

(Continue reading)

headers

J. B. Rainsberger | 25 Aug 2004 19:47

Re: Suggestions on how to approach TDD for this problem?

Russell Gold wrote:

> On Tue, 24 Aug 2004 10:55:54 -0400, J. B. Rainsberger
> <jbrains <at> rogers.com> wrote:
> 
>>I agree with you, but I have been experimenting with only one
>>constructor for each object, and pushing the rest to creation methods. I
>>can't say I notice much of a difference, so far.
> 
> You mean static creation methods all calling a single private
> constructor and calling setters (possibly private) to add anything
> else? 

The creation method doesn't have to be class-level, but I do use that 
technique.

> Or does your constructor take the superset of initialization
> values and rely on the creation methods to supply the appropriate
> values?

I prefer constructors to take as many parameters as is comfortable. 
Beyond that, I use Builders.

> How do you deal with subclasses?

I can't think of a problem I've had, so I'd have to say "with no 
additional effort". :)
--

-- 
J. B. Rainsberger,
Diaspar Software Services

(Continue reading)

headers

Paul Michali | 2 Sep 2004 14:01

Re: Suggestions on how to approach TDD for this problem?

Just an update on this for everyone and some more
questions...

I've been able to successfully read in the Excel
spreadsheet of info using POI, as suggested, and then
filter, slightly massage, and write to a MySQL database.

Design question

I stuck with my scheme of creating a Member object with
a ctor that took no args (and which set the member ID
to -1, which means invalid member) and then populated
the fields of the class by calling set methods versus
having a ctor that took 20+ args.

The reason, which I'd like to hear what people think
about this so I can learn, is that with a ctor that
takes so many args, all of which are strings, seemed
like it would be more error prone for users of the
class.

So, I have this:

public Member() {
     number = NO_MEMBER_ID;
     ...
}

Then in a routine that creates the object...

(Continue reading)

headers

J. B. Rainsberger | 2 Sep 2004 14:11

Re: Suggestions on how to approach TDD for this problem?

Paul Michali wrote:

> The reason, which I'd like to hear what people think
> about this so I can learn, is that with a ctor that
> takes so many args, all of which are strings, seemed
> like it would be more error prone for users of the
> class.

I have played with representing those objects as "typed Maps" -- a 
Map-like interface (name -> value) where you can specify the type of the 
values for runtime type safety. The resulting interface would be --

values = new HashMap();
values.put("number", new Integer(1234));
values.put("name", "J. B. Rainsberger");
values.put("address", "... Toronto, ON ...");

member = Member.create(values);

Member.create(Map values) {
     Member member = new Member();
     members.copyFrom(values);
     return member;
}

I was essentially giving up compile-time safety for flexibility in the 
interface and better support for generic algorithms. I liked it, 
especially when it came time to shuttle data back and forth between the 
web UI and the application.

(Continue reading)

headers

Andrew McDonagh | 2 Sep 2004 14:50

RE: Suggestions on how to approach TDD for this problem?


How about changing the Ctor so that it accepts a single param.  This param
would be the 'thing' which the Ctro uses to get the necessary values from.

class ContentProvider  {

	public String getA();
	public String getB();
	public String getC();
	public String getD();
	public String getE();
}

Class Member {

	public Member(ContentProvider provider) {
		this.a = provider.getA();
		this.b = provider.getB();
		this.c = provider.getC();
		this.d = provider.getD();
		this.e = provider.getE();
	}

}

Kinda like visitor....the Ctor could even be made private and appropriate
factory methods employed to 'visit' the provider.

> -----Original Message-----
> From: J. B. Rainsberger [mailto:jbrains <at> rogers.com]

(Continue reading)

headers

Paul Michali | 2 Sep 2004 16:01

Re: Suggestions on how to approach TDD for this problem?

Andrew McDonagh wrote:

> How about changing the Ctor so that it accepts a single param.  This param
> would be the 'thing' which the Ctro uses to get the necessary values from.
> 
> class ContentProvider  {
> 
> 	public String getA();
> 	public String getB();
> 	public String getC();
> 	public String getD();
> 	public String getE();
> }
> 
> Class Member {
> 
> 	public Member(ContentProvider provider) {
> 		this.a = provider.getA();
> 		this.b = provider.getB();
> 		this.c = provider.getC();
> 		this.d = provider.getD();
> 		this.e = provider.getE();
> 	}
> 
> }
> 
> Kinda like visitor....the Ctor could even be made private and appropriate
> factory methods employed to 'visit' the provider.

I have a SpreadsheetDataSource class that reads a row

(Continue reading)

headers

Andrew McDonagh | 2 Sep 2004 16:36

RE: Suggestions on how to approach TDD for this problem?


> -----Original Message-----
> From: Paul Michali [mailto:pcm <at> cisco.com]
> Sent: 02 September 2004 15:02
> To: testdrivendevelopment <at> yahoogroups.com
> Subject: Re: [TDD] Suggestions on how to approach TDD for this problem?
>
>
> Andrew McDonagh wrote:
>
> > How about changing the Ctor so that it accepts a single param.
> This param
> > would be the 'thing' which the Ctro uses to get the necessary
> values from.
> >
> > class ContentProvider  {
> >
> > 	public String getA();
> > 	public String getB();
> > 	public String getC();
> > 	public String getD();
> > 	public String getE();
> > }
> >
> > Class Member {
> >
> > 	public Member(ContentProvider provider) {
> > 		this.a = provider.getA();
> > 		this.b = provider.getB();
> > 		this.c = provider.getC();

(Continue reading)

headers

Peter Gummer | 25 Aug 2004 02:07

Re: Suggestions on how to approach TDD for this problem?

>From: "J. B. Rainsberger" <jbrains <at> rogers.com>
>... I have been experimenting with only one
>constructor for each object ...

Surely you mean one constructor for each class?

- Peter Gummer

_________________________________________________________________
In the market for a car? Buy, sell or browse at CarPoint:   
http://server-au.imrworldwide.com/cgi-bin/b?cg=link&ci=ninemsn&tu=http://carpoint.ninemsn.com.au?refid=hotmail_tagline

------------------------ Yahoo! Groups Sponsor --------------------~--> 
$9.95 domain names from Yahoo!. Register anything.
http://us.click.yahoo.com/J8kdrA/y20IAA/yQLSAA/NhFolB/TM
--------------------------------------------------------------------~-> 

 
Yahoo! Groups Links

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

<*> 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/

(Continue reading)

headers

J. B. Rainsberger | 25 Aug 2004 15:00

Re: Suggestions on how to approach TDD for this problem?

Peter Gummer wrote:
>>From: "J. B. Rainsberger" <jbrains <at> rogers.com>
>>... I have been experimenting with only one
>>constructor for each object ...
> 
> Surely you mean one constructor for each class?

Yes, of course. I'm one of these poor saps who interchanges "class" and 
"object" in informal discourse. :)
-- 
J. B. Rainsberger,
Diaspar Software Services
http://www.diasparsoftware.com :: +1 416 791-8603
Let's write software that people understand

------------------------ Yahoo! Groups Sponsor --------------------~--> 
$9.95 domain names from Yahoo!. Register anything.
http://us.click.yahoo.com/J8kdrA/y20IAA/yQLSAA/NhFolB/TM
--------------------------------------------------------------------~-> 

 
Yahoo! Groups Links

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

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

<*> Your use of Yahoo! Groups is subject to:

(Continue reading)

headers

Paul Michali | 24 Aug 2004 20:35

Re: Suggestions on how to approach TDD for this problem?

>>I personally would broaden this to say that there should be only one 
>>constructor that does the real construction.  I think it's OK to have other 
>>constructors with different signatures as long as they in turn call the One 
>>True Constructor to do the work.
>>
>>Is that evil?  I see the value in not having multiple constructors with 
>>similar code in them, for sure.
> 
> 
> I agree with you, but I have been experimenting with only one 
> constructor for each object, and pushing the rest to creation methods. I 
> can't say I notice much of a difference, so far.

Well my code's evolving still. For the Member class, I have a
very simple ctor (that came out of the TDD process I was trying
to do):

	public Member() {
		number = NO_MEMBER_ID;
	}
		

This is my "null object", where it uses a member ID # of -1,
which is invalid. Then, as I started reading fields of a
row from the spreadsheet, I created generic routines to
read a cell in a row (one for text, one for numbers, one
for dates). The DAO object, which deals with processing an
entire row, builds a full Member, by first asking the Data
Source object to read a row, and then it calls set functions
that take each field (using the context of the domain and

(Continue reading)

headers

Rob Syvertsen | 23 Aug 2004 18:44

RE: Suggestions on how to approach TDD for this problem?

Paul Michali wrote:

>Well, sort of. If I want to have a fully created Member
>object that I then give to dao.create(), then yes, it is
>easier (having a ctor with all the fields versus an empty
>ctor and calling N set functions).

>For the first go at this, I just created a member with
>only the fields that are used in the "primary key" filled
>out and then called dao.create(member). I guess as I go
>farther with this I'll hit a point where I need to fully
>create the member and then I can create a ctor that takes
>all of the fields.

I think the standard answer for this is to write it once just to get the
tests working and leave it, but the second time you have to write all those
function calls to fill in the member fields, then refactor them out.  This
is where that constructor would come from I think.

Rob

------------------------ Yahoo! Groups Sponsor --------------------~--> 
Make a clean sweep of pop-up ads. Yahoo! Companion Toolbar.
Now with Pop-Up Blocker. Get it for free!
http://us.click.yahoo.com/L5YrjA/eSIIAA/yQLSAA/NhFolB/TM
--------------------------------------------------------------------~-> 

 
Yahoo! Groups Links

(Continue reading)

headers

Paul Michali | 23 Aug 2004 17:46

Re: Suggestions on how to approach TDD for this problem?

Paul Michali wrote:

> Right now I've hit a small snag in testing of the DAO
> for SQL. I had created tests for the DataSource and was
> able to verify that, with a Member that consists only of
> the "primary key" fields (name, ID#), I can:
> 
> - create the empty table
> - insert the "member" entry in the table
> - insert member into a different table name
> - find an entry in a table
> - create in one table, verify not found in another
> - verify find fails, when key doesn't match
> 
> Then, I started on the DAO tests, starting with create().
> I then did a find(), but it did not find the entry. I
> commented out the SQL code in the setup()/teardown() that
> does a "drop" on the table and I don't see the created
> entry, so I've got two things to do:
> 
> - Figure out why the DAO object cannot create the row
>    but the DataSource can.

Looks like the table rows are getting created. I was working
from two machines (home and work) and in the process, some
changes I did on one didn't get "committed" so things were a
bit out of whack. In the backtracing of my steps, I had commented
out the code in teardown(), but not in setup(), so all tables
were getting "dropped" at the start of each test, hence I wasn't
seeing the one table I was expecting.

(Continue reading)

headers

pc_michali | 21 Aug 2004 19:37

Re: Suggestions on how to approach TDD for this problem?


--- In testdrivendevelopment <at> yahoogroups.com, "J. B. Rainsberger"
<jbrains <at> r...> wrote:
> Kaoru Hosokawa wrote:

> > Have you looked at this page? It explains DAO and gives an example  
> > which looks similar to what you want.
> > 
> > http://java.sun.com/blueprints/corej2eepatterns/Patterns/ 
> > DataAccessObject.html

Thanks for the link. I like the fact that it summarizes all the
related patterns. Other people have referred me to several links
on the DAO pattern, so I've been reading and digesting the info.

> 
> I use a different approach.
> 
> public void testCreateMember() throws Exception {
>      MySqlMemberDAO memberDao = new MySqlMemberDAO();
> 
>      Member paul = Member.create(1234, "Paul Michali");
>      dao.create(paul);
> 
>      // execute query 'select count(*) from member where id=1234'
>      // assert count is 1
> }
> 
> This works well until you have multiple DAOs, each of whose test 
> duplicates all this SQL/JDBC nonsense. The answer is to extract the

(Continue reading)

headers

J. B. Rainsberger | 23 Aug 2004 03:17

Re: Suggestions on how to approach TDD for this problem?

pc_michali wrote:

> --- In testdrivendevelopment <at> yahoogroups.com, "J. B. Rainsberger"
> <jbrains <at> r...> wrote:
> 
>>Kaoru Hosokawa wrote:
> 
> 
>>>Have you looked at this page? It explains DAO and gives an example  
>>>which looks similar to what you want.
>>>
>>>http://java.sun.com/blueprints/corej2eepatterns/Patterns/ 
>>>DataAccessObject.html
> 
> Thanks for the link. I like the fact that it summarizes all the
> related patterns. Other people have referred me to several links
> on the DAO pattern, so I've been reading and digesting the info.

An alternative design, which I prefer, uses Repository interfaces and is 
described wonderfully in _Domain Driven Design_ by my good friend Eric 
Evans.

>>I use a different approach.
>>
>>public void testCreateMember() throws Exception {
>>     MySqlMemberDAO memberDao = new MySqlMemberDAO();
>>
>>     Member paul = Member.create(1234, "Paul Michali");
>>     dao.create(paul);
>>

(Continue reading)

headers

Kaoru Hosokawa | 21 Aug 2004 11:23

Re: Suggestions on how to approach TDD for this problem?


On 2004/08/21, at 15:30, J. B. Rainsberger wrote:

>
> Kaoru Hosokawa wrote:
>
>>> - Is this the most basic test to start with?
>>
>> If the purpose of your test is to check whether the creation of
>> MySqlMemberDAO was successful or not, I think the following  test is
>> more basic.
>>
>> public void testCreate() {
>> 	assertNotNull(new MySqlMemberDAO());
>> }
>
> The Java Language Specification proves that this can't fail unless the
> compiler or interpreter is broken. Don't Test the Platform.
>

You're right. You don't need to test new.

Kaoru Hosokawa
khosokawa <at> mac.com

------------------------ Yahoo! Groups Sponsor --------------------~--> 
Make a clean sweep of pop-up ads. Yahoo! Companion Toolbar.
Now with Pop-Up Blocker. Get it for free!
http://us.click.yahoo.com/L5YrjA/eSIIAA/yQLSAA/NhFolB/TM
--------------------------------------------------------------------~->

(Continue reading)

headers

רועי אושרוב | 3 Aug 2004 14:50

RE: Suggestions on how to approach TDD for this problem?

I agree. I'd test a component that receives and Excel file name and returns "hello".

In the first test I'd actually return a hard coded "hello" and then make another test that should return a
different string with a different file name.

After that:

For the excel reader:

-          test that given an excel sheet with one membership info you get back not a string, but an object which
represents membership info.

-          (make that test work with a hard coded new instance of membership info class)

-          Test that given an excel sheeth with twmo membership infos you get back two info objects with the same
property values.

-          And so on and so forth

For the DB writer:

            -test that there is a DBWrite object that receives a collection of membership info objects

            -  make sure it actually saves in the database by checking the number of actual rows after each write.

And go on from there.

________________________________

From: Ron Jeffries [mailto:jeffries <at> dundee.net]

(Continue reading)

headers

Paul Michali | 5 Aug 2004 19:04

Re: Suggestions on how to approach TDD for this problem?

???? ?????? wrote:

> I agree. I'd test a component that receives and Excel file name and
 > returns "hello".
> 
> In the first test I'd actually return a hard coded "hello" and then
 > make another test that should return a different string with a
 > different file name.

OK. I've gotten this far, using the POI classes that Martin Wegner
suggested, to access Excel (instead of JDBC/ODBC that I had before).
This brings up a question, namely, that I intend on writing out the
data to a database, so I will be using JDBC on the other end, so
does it make sense to use JDBC on this end too, or is that premature?

Should I just continue with the POI HSSF classes to read the
spreadsheet?

Right now, I have the ctor, that just gets the filename
and one method, contents() that returns the contents of
the first cell from the first row, on the first sheet.

Note: in the live database, there is a header row.

> After that:
> 
> For the excel reader:
> 
> - test that given an excel sheet with one membership info
 > you get back not a string, but an object which represents

(Continue reading)

headers

Roy Osherove | 5 Aug 2004 21:18

RE: Suggestions on how to approach TDD for this problem?


> I agree. I'd test a component that receives and Excel file name and
> returns "hello".
> 
> In the first test I'd actually return a hard coded "hello" and then
> make another test that should return a different string with a
> different file name.

OK. I've gotten this far, using the POI classes that Martin Wegner
suggested, to access Excel (instead of JDBC/ODBC that I had before).
This brings up a question, namely, that I intend on writing out the
data to a database, so I will be using JDBC on the other end, so
does it make sense to use JDBC on this end too, or is that premature?

>>> 

I usually write tests that in return will get hard coded or easy top produce
values until I reach a point where just making up return values does not cut
it in simplicity and length of code. For example - after about 2,3 test of
testing return values for different file names I'd get to appoint where its
just easier to read the darned spreadsheet than it is to make up values.
Same for DB. I'd write a test that calls "save" or what not, but after that
I'd probably write a test that either goes directly to the test DB and
checks that the new row exists (and after that a test that checks that row's
values). Such tests usually make the tested code go to the database to solve
the "breaking test". The hard thing is solving these things still as simply
as possible and not in a too generic way. 

Should I just continue with the POI HSSF classes to read the
spreadsheet?

(Continue reading)

headers

Phlip | 5 Aug 2004 22:27

RE: Suggestions on how to approach TDD for this problem?

Roy Osherove wrote:

> OK. I've gotten this far, using the POI classes that
> Martin Wegner
> suggested, to access Excel (instead of JDBC/ODBC
> that I had before).
> This brings up a question, namely, that I intend on
> writing out the
> data to a database, so I will be using JDBC on the
> other end, so
> does it make sense to use JDBC on this end too, or
> is that premature?

YAGNI and DoSimpleThings are advanced topics.

At this level, simplicity comes from leveraging what
you know. If you know databases, and if writing and
parsing a raw text file would be less simple, go with
the former.

If you were architecting an enterprise...

=====
Phlip
  http://industrialxp.org/community/bin/view/Main/TestFirstUserInterfaces

__________________________________
Do you Yahoo!?

(Continue reading)

headers

Ron Jeffries | 3 Aug 2004 13:51

Re: Suggestions on how to approach TDD for this problem?

On Tuesday, August 3, 2004, at 7:22:35 AM, Paul Michali wrote:

> I'm having trouble figuring out how to get started
> with TDD. My first story is one that reads the spreadsheet
> and writes to a SQL database to effectively "import" the
> new month info. I'm starting with the first part, "read
> the data from the spreadsheet". Can anyone advise on how
> I approach this test-first?

Well, I think I'd not be where you are. But if I were where you are, I'd
write a test that opens a spreadsheet containing A1="Hello", and read the
Hello out of it. :) But seriously, that's what I'd do.

If that took too long (more than ten minutes) I'd try to think of something
simpler, probably either whatever was currently working, or whatever seemed
to be blocking me.

Ron Jeffries
www.XProgramming.com
Now -- Bring me that horizon.  -- Captain Jack Sparrow

------------------------ Yahoo! Groups Sponsor --------------------~--> 
Yahoo! Domains - Claim yours for only $14.70
http://us.click.yahoo.com/Z1wmxD/DREIAA/yQLSAA/NhFolB/TM
--------------------------------------------------------------------~-> 

Yahoo! Groups Links

<*> To visit your group on the web, go to:

(Continue reading)

headers

Paul Michali | 3 Aug 2004 15:50

Re: Suggestions on how to approach TDD for this problem?

Ron Jeffries wrote:

> On Tuesday, August 3, 2004, at 7:22:35 AM, Paul Michali wrote:
> 
> 
>>I'm having trouble figuring out how to get started
>>with TDD. My first story is one that reads the spreadsheet
>>and writes to a SQL database to effectively "import" the
>>new month info. I'm starting with the first part, "read
>>the data from the spreadsheet". Can anyone advise on how
>>I approach this test-first?
> 
> 
> Well, I think I'd not be where you are. But if I were where you are, I'd
> write a test that opens a spreadsheet containing A1="Hello", and read the
> Hello out of it. :) But seriously, that's what I'd do.
> 
> If that took too long (more than ten minutes) I'd try to think of something
> simpler, probably either whatever was currently working, or whatever seemed
> to be blocking me.

Thanks, Ron. I'll give it a try - reading just a cell from
the spreadsheet. In that case, would you start with a test
to see if you could just connect to the (Excel spreadsheet)
database?

Part of the problem may be that my view is tainted by the
work I did on the first version.

Regarding not being where I am, do you mean you would approach

(Continue reading)

headers

Ron Jeffries | 3 Aug 2004 20:14

Re: Suggestions on how to approach TDD for this problem?

On Tuesday, August 3, 2004, at 9:50:27 AM, Paul Michali wrote:

> Thanks, Ron. I'll give it a try - reading just a cell from
> the spreadsheet. In that case, would you start with a test
> to see if you could just connect to the (Excel spreadsheet)
> database?

Well, I haven't looked at the code to connect, so I don't know. I suspect
I'd write the test I described, read A1 from some file and find "Hello".

> Part of the problem may be that my view is tainted by the
> work I did on the first version.

> Regarding not being where I am, do you mean you would approach
> the problem differently or something else. Please elaborate,
> as maybe a totally different approach would be enlightening.

The application doesn't sound to me as if it needs a database. If I wanted
a database, I wouldn't use Excel, and I don't see why I'd want a database.

> Is there anything from the way I'm looking at the problem
> that you would consider differently (being the customer,
> developer, and relying on my split personality to pair
> program, may be causing some problems here :^)

Hard to tell from here. We'd have to talk about it, work on it, etc.

Ron Jeffries
www.XProgramming.com
Make it real or else forget about it  -- Carlos Santana

(Continue reading)

headers

Paul Michali | 4 Aug 2004 03:50

Re: Suggestions on how to approach TDD for this problem?

Ron Jeffries wrote:

>>Regarding not being where I am, do you mean you would approach
>>the problem differently or something else. Please elaborate,
>>as maybe a totally different approach would be enlightening.
> 
> 
> The application doesn't sound to me as if it needs a database. If I wanted
> a database, I wouldn't use Excel, and I don't see why I'd want a database.

Oh, let me clarify a bit. I get monthly reports from the
National club office. The report contains the current
membership information as an Excel spreadsheet. It has
redundant fields, info that I'd never use, awkwardly
encoded fields, and no unique key (there is a member
number, but it is shared by members and associate
members). They show current, new (for that month) and
expired (for that month) members.

There are two things here. First, I want to accumulated
and maintain the expired members over the months, so
that I can do analysis on it. Second, I'm often asked
for information, like what is a member's ID #, which
members own a certain model, how many members are there
in each county, etc.

I thought that a database would be a nice way to store
and then retrieve that information, just by doing SQL
queries.

(Continue reading)

headers

Ian D. Stewart | 6 Aug 2004 10:56

Re: Suggestions on how to approach TDD for this problem?

On Tuesday 03 August 2004 21:50, Paul Michali wrote:

>
> Oh, let me clarify a bit. I get monthly reports from the
> National club office. The report contains the current
> membership information as an Excel spreadsheet. It has
> redundant fields, info that I'd never use, awkwardly
> encoded fields, and no unique key (there is a member
> number, but it is shared by members and associate
> members). They show current, new (for that month) and
> expired (for that month) members.
>
> There are two things here. First, I want to accumulated
> and maintain the expired members over the months, so
> that I can do analysis on it. Second, I'm often asked
> for information, like what is a member's ID #, which
> members own a certain model, how many members are there
> in each county, etc.

Paul,

It seems to me that these are your user stories.  The rest is implementation 
details.  Use these stories, in combination with the technology and skill 
sets at your disposal to identify the implementation details.  By tying the 
tests to the user stories instead of the implementation details, you are free 
to change the implementation details whenever either of the latter two 
changes without breaking your tests (and therefor your app).

HTH,
Ian

(Continue reading)

headers

Ron Jeffries | 4 Aug 2004 04:47

Re: Suggestions on how to approach TDD for this problem?

On Tuesday, August 3, 2004, at 9:50:14 PM, Paul Michali wrote:

>> The application doesn't sound to me as if it needs a database. If I wanted
>> a database, I wouldn't use Excel, and I don't see why I'd want a database.

> Oh, let me clarify a bit. I get monthly reports from the
> National club office. The report contains the current
> membership information as an Excel spreadsheet. It has
> redundant fields, info that I'd never use, awkwardly
> encoded fields, and no unique key (there is a member
> number, but it is shared by members and associate
> members). They show current, new (for that month) and
> expired (for that month) members.

This certainly explains why we need to read Excel. But don't you already
have an Excel reading capability then? I thought you were just starting on
that. Or is this a new story?

> There are two things here. First, I want to accumulated
> and maintain the expired members over the months, so
> that I can do analysis on it. Second, I'm often asked
> for information, like what is a member's ID #, which
> members own a certain model, how many members are there
> in each county, etc.

> I thought that a database would be a nice way to store
> and then retrieve that information, just by doing SQL
> queries.

I understand people thinking that. I might have gotten to a database, but

(Continue reading)

headers

Paul Michali | 4 Aug 2004 13:23

Re: Suggestions on how to approach TDD for this problem?

Ron Jeffries wrote:
> On Tuesday, August 3, 2004, at 9:50:14 PM, Paul Michali wrote:
> 
>>Oh, let me clarify a bit. I get monthly reports from the
>>National club office. The report contains the current
>>membership information as an Excel spreadsheet. It has
>>redundant fields, info that I'd never use, awkwardly
>>encoded fields, and no unique key (there is a member
>>number, but it is shared by members and associate
>>members). They show current, new (for that month) and
>>expired (for that month) members.
> 
> 
> This certainly explains why we need to read Excel. But don't you already
> have an Excel reading capability then? I thought you were just starting on
> that. Or is this a new story?

I'm trying to redesign, from scratch, an application
to do all this, so that I can try it using TDD w/Java
(learning exercise). So, I have a story that is to
read in the Excel spreadsheet and that is the story
that I'm trying to approach first.

>>I thought that a database would be a nice way to store
>>and then retrieve that information, just by doing SQL
>>queries.
> 
> 
> I understand people thinking that. I might have gotten to a database, but
> rarely do.

(Continue reading)

headers

Cory Foy | 5 Aug 2004 04:58

Re: Suggestions on how to approach TDD for this problem?

Paul Michali wrote:
>>>Oh, let me clarify a bit. I get monthly reports from the
>>>National club office. The report contains the current
>>>membership information as an Excel spreadsheet. It has
>>>redundant fields, info that I'd never use, awkwardly
>>>encoded fields, and no unique key (there is a member
>>>number, but it is shared by members and associate
>>>members). They show current, new (for that month) and
>>>expired (for that month) members.

I've been there several times. Basically you have a process that you 
don't control, but want to do what you can control using TDD. Be 
thankful it is Excel, I've certainly done my share of EDI and Flat file. 
The current project I'm on has us using a 1500-character fixed-length 
flat file. But I digress.

I think you were right in your original post that you are "tainted" by 
having written in and run the system. You are very close to it, so that 
makes it harder to see everything. Since you are doing this as an 
exercise to TDD, and it isn't mission critical, I would step way back 
and start from the very beginning. Meaning, ignore for a moment the fact 
that you have to read in a spreadsheet. Start with where you want to 
finish, and work backwards.

Here is a snippet from "Test-Driven Development By Example" by Kent Beck 
that explains better than I can what I am talking about:

//BEGIN SNIPPET

Here's an example. Suppose we want to communicate with another system

(Continue reading)

headers

Ian D. Stewart | 6 Aug 2004 10:41

Re: Suggestions on how to approach TDD for this problem?

On Wednesday 04 August 2004 22:58, Cory Foy wrote:
> Paul Michali wrote:
> >>>Oh, let me clarify a bit. I get monthly reports from the
> >>>National club office. The report contains the current
> >>>membership information as an Excel spreadsheet. It has
> >>>redundant fields, info that I'd never use, awkwardly
> >>>encoded fields, and no unique key (there is a member
> >>>number, but it is shared by members and associate
> >>>members). They show current, new (for that month) and
> >>>expired (for that month) members.
>
> I've been there several times. Basically you have a process that you
> don't control, but want to do what you can control using TDD. Be
> thankful it is Excel, I've certainly done my share of EDI and Flat file.
> The current project I'm on has us using a 1500-character fixed-length
> flat file. But I digress.

Been there done that, back again! ;)

Worked on one project where the data was stored in individual MS Word files 
(one file per record) and the difference between field labels and values was 
based on font characteristic (field labels were bold, values were not).

Compared to that Excel (which appears to be the enterprise standard for data 
representation) is a walk in the park!

Ian

--

-- 
Am fear nach gleidh na h-airm san t-sith,

(Continue reading)

headers

Phlip | 3 Aug 2004 16:36

Re: Suggestions on how to approach TDD for this problem?

Paul Michali wrote:

> I'm having trouble figuring out how to get started
> with TDD. My first story is one that reads the
> spreadsheet
> and writes to a SQL database to effectively
> "import" the
> new month info. I'm starting with the first part,
> "read
> the data from the spreadsheet". Can anyone advise
> on how
> I approach this test-first?

You have a cognitive mismatch here. The behaviors the
user sees on the screen don't match the ones whose
tests will seed this situation.

Most spreadsheets have a backdoor. Excel has an OLEDB
driver, so you can write a simple program that reads a
spreadsheet on one ADO channel, and writes its data to
a database on another ADO channel.

There's something to be said for stating User Stories
in terms of user experience. Was there a simpler way?

=====
Phlip
  http://industrialxp.org/community/bin/view/Main/TestFirstUserInterfaces

(Continue reading)

headers

Paul Michali | 4 Aug 2004 03:42

Re: Suggestions on how to approach TDD for this problem?

Phlip wrote:

> Paul Michali wrote:
> 
> 
>>I'm having trouble figuring out how to get started
>>with TDD. My first story is one that reads the
>>spreadsheet
>>and writes to a SQL database to effectively
>>"import" the
>>new month info. I'm starting with the first part,
>>"read
>>the data from the spreadsheet". Can anyone advise
>>on how
>>I approach this test-first?
> 
> 
> You have a cognitive mismatch here. The behaviors the
> user sees on the screen don't match the ones whose
> tests will seed this situation.
> 
> Most spreadsheets have a backdoor. Excel has an OLEDB
> driver, so you can write a simple program that reads a
> spreadsheet on one ADO channel, and writes its data to
> a database on another ADO channel.

I'm not familiar with this. Do you know of any pointers
to info on this?

>

(Continue reading)

headers

Phlip | 4 Aug 2004 04:04

Re: Suggestions on how to approach TDD for this problem?

--- Paul Michali <pcm <at> cisco.com> wrote:

> Phlip wrote:

> > Most spreadsheets have a backdoor. Excel has an
> > OLEDB
> > driver, so you can write a simple program that
> > reads a
> > spreadsheet on one ADO channel, and writes its
> > data to
> > a database on another ADO channel.
> 
> I'm not familiar with this. Do you know of any
> pointers
> to info on this?

This site has megabytes of answers and examples on the
subject:

   http://groups.google.com

=====
Phlip
  http://industrialxp.org/community/bin/view/Main/TestFirstUserInterfaces

	
		
__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - 100MB free storage!

(Continue reading)

headers

Martin Wegner | 3 Aug 2004 16:54

Re: Suggestions on how to approach TDD for this problem?


If you are working in Java you can use Jakarta POI to read an Excel spread
sheet:

   http://jakarta.apache.org/poi/index.html

--- Phlip <phlipcpp <at> yahoo.com> wrote:

> Paul Michali wrote:
> 
> > I'm having trouble figuring out how to get started
> > with TDD. My first story is one that reads the
> > spreadsheet
> > and writes to a SQL database to effectively
> > "import" the
> > new month info. I'm starting with the first part,
> > "read
> > the data from the spreadsheet". Can anyone advise
> > on how
> > I approach this test-first?
> 
> You have a cognitive mismatch here. The behaviors the
> user sees on the screen don't match the ones whose
> tests will seed this situation.
> 
> Most spreadsheets have a backdoor. Excel has an OLEDB
> driver, so you can write a simple program that reads a
> spreadsheet on one ADO channel, and writes its data to
> a database on another ADO channel.
>

(Continue reading)

headers

Paul Michali | 4 Aug 2004 03:43

Re: Suggestions on how to approach TDD for this problem?

Martin Wegner wrote:

> If you are working in Java you can use Jakarta POI to read an Excel spread
> sheet:
> 
>    http://jakarta.apache.org/poi/index.html

Thanks. I'll look at it.

PCM WORKING  <at>  HOME (Paul Michali)

------------------------ Yahoo! Groups Sponsor --------------------~--> 
Make a clean sweep of pop-up ads. Yahoo! Companion Toolbar.
Now with Pop-Up Blocker. Get it for free!
http://us.click.yahoo.com/L5YrjA/eSIIAA/yQLSAA/NhFolB/TM
--------------------------------------------------------------------~-> 

 
Yahoo! Groups Links

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

<*> 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/

(Continue reading)