headers
samuel | 1 Jan 2005 17:33
Picon
Picon

Re: Testing DB drivers


On Mon, Dec 27, 2004 at 11:24:20PM -0500, Tim Welch wrote:
> 
> 
> > Tell us a bit more about what you're testing and how the tests work,
> > in this regard?

 << Snip >>

> Other than mocking the socket, I can't think of another solution that is 
> even remotely feasible. As I said, I'm not sure even mocking the socket 
> is a feasible solution.
> 
> Any ideas?

Could you configure the DB to run on an in-memory virtual disk instead
of the harddrive?

HTH
//Samuel

 
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
(Continue reading)

Permalink | Reply | 0 comments |
headers
Donaldson, John (GEO | 3 Jan 2005 12:11
Picon
Favicon

RE: Testing DB drivers


Tim,

surely you are better off with the tests than without them.
So, can you partition them and just run a fairly-fast subset 
most of the time, and run the full battery two or three times
a day? It will not be perfect, but it may be the best you can
do.

I am working with a situation which is similar (not the same
but that's another story). I just accept that I aren't anywhere
near the TDD perfection of running all my tests in next to no
time after a tiny change. It just can't be done in my case,
and it sounds likely that you can't get perfaction in yours
either.

John D. 

-----Original Message-----
From: Tim Welch [mailto:tim <at> welchnet.org] 
Sent: Thursday, December 30, 2004 11:42 PM
To: testdrivendevelopment <at> yahoogroups.com
Subject: Re: [TDD] Testing DB drivers

> I think you skipped over the part of my post where I described how I 
> test the database layer, also.

Perhaps I haven't been clear what my problem is. I know how to test the
database layer.
(Continue reading)

Permalink | Reply | 501 comments |
headers
Hubert Baumeister | 3 Jan 2005 16:38
Picon

Call for Papers - XP 2005, June 18-23, 2005 Sheffield University, UK


                                    Sixth International Conference on
                                 eXtreme Programming and Agile Processes
                                         in Software Engineering

                                                XP 2005

                                June 18-23, 2005 Sheffield University, UK

http://www.xp2005.org

The Sixth International Conference on eXtreme Programming and Agile
Processes in Software Engineering is a unique forum for industry and
academic professionals to discuss their needs and ideas for
incorporating eXtreme Programming and agile methodologies into their
professional life under consideration of social aspects.

XP 2005 facilitates to swap ideas in a number of ways, including
featured talks by professionals on the cutting edge of eXtreme
Programming and Agile Processes, technical presentations, special
activity sessions, panels, posters, code camps, workshops, tutorials
and other opportunities to exchange and elaborate on new findings. XP
2005 features additionally a PhD Symposium for PhD students.

CONFERENCE TOPICS

The conference will stress practical applications and implications of
XP and other agile methodologies (AM). Conference topics include, but
are not limited to:
(Continue reading)

Permalink | Reply | 0 comments |
headers
J. B. Rainsberger | 4 Jan 2005 01:43
Favicon

Re: Testing DB drivers


Tim Welch wrote:

> If I was working on a DB application this would be how I would test as 
> well. However, what I am writing is the actual DB driver (e.g. ADO.NET 
> data provider). The entire product *is* the DB layer.

I've never written a database driver, but I suspect that there is, for 
example, some Java code and some native code, and a bridge between the 
two. To test the Java part, mock out or fake out the native part as 
needed. To test the native part, well, I hope you're writing it in a 
language that also has an xUnit framework already written for you.

Not a satisfying answer, but the best I can think of at present. I 
wonder what the others have said. I think I'll read on.
--

-- 
J. B. (Joe) Rainsberger
Diaspar Software Services
http://www.diasparsoftware.com
Author, JUnit Recipes: Practical Methods for Programmer Testing

 
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
(Continue reading)

Permalink | Reply | 0 comments |
headers
J. B. Rainsberger | 4 Jan 2005 01:40
Favicon

Re: How i can test a Hibernate query


it_inkom wrote:

> I want test Hibernate query. How can i do it?

If you want to verify that the query returns the expected data, then I'm 
not sure you can avoid using a database. The good news is that you can 
use HSQLDB in in-memory mode and dramatically (I believe) speed up the 
tests.

> I hope there is a better solution rather than testing agains a live
> database using DBUnit. I don't want to test all queries agains a
> database. It very slow and difficult to write. I have to write *.java
> and *.xml files. Too much lines of test code for few lines of
> production code.

That might be, but if you want to test the query, then you have to 
execute it somehow.
--

-- 
J. B. (Joe) Rainsberger
Diaspar Software Services
http://www.diasparsoftware.com
Author, JUnit Recipes: Practical Methods for Programmer Testing

 
Yahoo! Groups Links

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

Permalink | Reply | 0 comments |
headers
J. B. Rainsberger | 4 Jan 2005 01:53
Favicon

Re: NMock for classes with static methods.


Peter Gummer wrote:
> On 29/12/2004, at 1:49 AM, George Dinwiddie wrote:
> 
> 

> After reading a couple of these examples, it dawned on me that the 
> author was applying an unstated rule: do the simplest thing that DOES 
> NOT INVOLVE STATICS. Refactoring works best when working with objects; 
> it is usually hindered by statics.
> 
> I guess this rule was so thoroughly ingrained in the mindset of both 
> authors that it occurred to neither of them to mention it in these two 
> books.

When I test-drive code and I don't know what object it wants to be on 
(yet), I do something even simpler than writing a class-level routine on 
some utility class: I add the method to the test case class itself. 
After writing a few tests, or the first time a production code class 
wants to invoke that method, it's usually clear on which class the 
methods wants to be. That's how I avoid class-level methods (except for 
creation methods), and I think that's consistent with "the simplest things".

Class-level methods eventually rely on global data, and global data 
rarely stays simple for long.
--

-- 
J. B. (Joe) Rainsberger
Diaspar Software Services
http://www.diasparsoftware.com
Author, JUnit Recipes: Practical Methods for Programmer Testing
(Continue reading)

Permalink | Reply | 1 comment |
headers
J. B. Rainsberger | 4 Jan 2005 01:55
Favicon

Re: NMock for classes with static methods.


yahoogroups <at> jhrothjr.com wrote:

> There's no benefit in doing something that
> you know will have to change.

Hm. I know you meant to just throw this in, but the way I interpret this 
statement, it's awfully inconsistent with incremental design. I'm 
surprised your subconscious let you write it. :)
--

-- 
J. B. (Joe) Rainsberger
Diaspar Software Services
http://www.diasparsoftware.com
Author, JUnit Recipes: Practical Methods for Programmer Testing

 
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/
Permalink | Reply | 2 comments |
headers
yahoogroups | 4 Jan 2005 02:12

Re: NMock for classes with static methods.


From: "J. B. Rainsberger" 
<jbrains.at.rogers.com <at> yahoogroups.at.jhrothjr.com>
To: "testdrivendevelopment <at> yahoogroups.com" 
<testdrivendevelopment.at.yahoogroups.com <at> yahoogroups.at.jhrothjr.com>
Sent: Monday, January 03, 2005 6:55 PM
Subject: Re: [TDD] NMock for classes with static methods.

>
> yahoogroups <at> jhrothjr.com wrote:
>
>> There's no benefit in doing something that
>> you know will have to change.
>
> Hm. I know you meant to just throw this in, but the way I interpret this
> statement, it's awfully inconsistent with incremental design. I'm
> surprised your subconscious let you write it. :)

The underlying question is: change it to what?
Even "fake it until you make it" recognizes
that you don't know (yet) what the final
result is going to be.

It's a question of not undercutting your knowing.

John Roth

> -- 
> J. B. (Joe) Rainsberger
> Diaspar Software Services
(Continue reading)

Permalink | Reply | 1 comment |
headers
J. B. Rainsberger | 4 Jan 2005 02:35
Favicon

Re: NMock for classes with static methods.


yahoogroups <at> jhrothjr.com wrote:

>>>There's no benefit in doing something that
>>>you know will have to change.
>>
>>Hm. I know you meant to just throw this in, but the way I interpret this
>>statement, it's awfully inconsistent with incremental design. I'm
>>surprised your subconscious let you write it. :)
> 
> The underlying question is: change it to what?
> Even "fake it until you make it" recognizes
> that you don't know (yet) what the final
> result is going to be.
> 
> It's a question of not undercutting your knowing.

I suppose so, but "Fake it" definitely tells me to do something that I 
know (really means "am pretty damn sure") I will have to change, even if 
I don't (yet) know the final result.

It's not terribly important; I just found it odd.
--

-- 
J. B. (Joe) Rainsberger
Diaspar Software Services
http://www.diasparsoftware.com
Author, JUnit Recipes: Practical Methods for Programmer Testing

 
Yahoo! Groups Links
(Continue reading)

Permalink | Reply | 0 comments |
headers
Sean Dockery | 4 Jan 2005 07:02

Re: Testing private methods


"William Tanksley, Jr" <wtanksleyjr <at> gmail.com> wrote in message
news:37d01e6704121112183ba28f5e <at> mail.gmail.com...
>
> Let me add that the example you give, of a null parameter, is an
> excellent example of where TDD can say nothing at all: when the
> desired rule is that something can "never" happen. Quite often I've
> been doing pure TDD, and realised that although a given function was
> complete, it would be easy to misuse. I just put a note about that in
> a comment and let it go.
>

I'm curious about what you've said here.  It sounds like you're saying that
when you know that an input value beyond the boundaries of acceptable input
values exists, that you simply document that those specific values cause
"undefined" behaviour--instead of writing a test to force yourself to define
behaviour for the illegal inputs.  Am I understanding you correctly?

It also seems to me that you're implying that you expect (require) that unit
tests of the consuming code will ensure that the consuming code would never
call the consumed code with a null input value?  Am I correct in that
assessment?

 
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:
(Continue reading)

Permalink | Reply | 4 comments |

Gmane