开云体育

Hi,

I'm new to tdd and i've read the book growing oo software. I'm trying to incorporate tdd into a sample project. Basically the project is an api that allows you to keep-alive various services, basically its a heartbeat. The book says to start out by designing a skeleton that is enough to get your application functioning and that which covers the core components. So the simplest end-to-end test I can think of is to send an http request and make sure the server received it. How should i structure this test? Should I have a fake http server and make a request to it and assert that the server received the request or should I just make a request to any arbitrary working url and get its return code?

I feel that my test case does not really cover the core components since the api has the ability to send keep alive requests to various services based on some various kinds trigger. Any suggestions on how to start?


Thanks.

+1

Put another way: perhaps your real system is not as free as you think it
is. Anything that takes extra time or introduces uncertainty is not "free"
in the sense that it takes additional resources to test.

You can TDD with microtests and do just enough integration testing right
before you check in to convince yourself that you've got it. Or, you could
start by writing some tests to probe the real system and see how it behaves
with various timings. Then you use those findings to guide the initial set
of microtests.

On Tue, Jul 17, 2012 at 8:47 PM, Tim Ottinger <tottinge@...> wrote:

**


On Tue, Jul 17, 2012 at 10:16 PM, xxtommo54xx <xxtommoxx@...>
wrote:

Basically i am supposed to send a message to keep a connection that has

a timeout value alive. The message is dependent on the protocol being
used
i.e http, rmi, etc. It is also supposed to manage a set of these and send
the messages depending on some sort of event (ex. a timed trigger).

In the book they clearly outlined the core components for the skeletal

design which is the sniper communicating to a fake xmpp auction which
outputs the result to the ui.

I just have trouble identifying the core components for the skeleton

which is used to kickstart the tdd proccess and how to test it. Would i
be
able to use an actual implementation as opposed to a fake implementation
(like the fake auction server)? The book mentioned that one of the
reasons
they used a fake auction server was because querying the real auction
server was not free. In my case, i can test using a real resource for
free.
Any suggestions?

It depends. Under what circumstances is it okay for your test not to
pass? Do you want to run it when the server isn't running, or maybe
when you're in a train/plane/taxi/oxcart and don't have a good
internet connection?

I put a lot of stock in whether a test isolates failures, but when it
talks to external services (file system, web service, etc) it starts
to get fuzzy. It might fail without the code being wrong in certain
circumstances.

See this:
(free to read).

--
Tim Ottinger, Sr. Consultant, Industrial Logic
-------------------------------------

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

Yahoo! Groups Links

Hi

If i understand your use case correctly i would start with fake Http
server. This way you could easily record its behavior - even if you decide
to switch to "real http server"one day it would be quite useful to have
some fake http server with behavior you can easily define in your tests.
Basically i am thinking of some corner cases like server not avialable,
server responds too slow and so on.

br Jakub

2012/7/17 xxtommo54xx <xxtommoxx@...>

**


Hi,

I'm new to tdd and i've read the book growing oo software. I'm trying to
incorporate tdd into a sample project. Basically the project is an api that
allows you to keep-alive various services, basically its a heartbeat. The
book says to start out by designing a skeleton that is enough to get your
application functioning and that which covers the core components. So the
simplest end-to-end test I can think of is to send an http request and make
sure the server received it. How should i structure this test? Should I
have a fake http server and make a request to it and assert that the server
received the request or should I just make a request to any arbitrary
working url and get its return code?

I feel that my test case does not really cover the core components since
the api has the ability to send keep alive requests to various services
based on some various kinds trigger. Any suggestions on how to start?

Thanks.

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

Hi

If i understand your use case correctly i would start with fake Http
server. This way you could easily record its behavior - even if you decide
to switch to "real http server"one day it would be quite useful to have
some fake http server with behavior you can easily define in your tests.
Basically i am thinking of some corner cases like server not avialable,
server responds too slow and so on.

br Jakub

2012/7/17 xxtommo54xx <xxtommoxx@...>

**


Hi,

I'm new to tdd and i've read the book growing oo software. I'm trying to
incorporate tdd into a sample project. Basically the project is an api that
allows you to keep-alive various services, basically its a heartbeat. The
book says to start out by designing a skeleton that is enough to get your
application functioning and that which covers the core components. So the
simplest end-to-end test I can think of is to send an http request and make
sure the server received it. How should i structure this test? Should I
have a fake http server and make a request to it and assert that the server
received the request or should I just make a request to any arbitrary
working url and get its return code?

I feel that my test case does not really cover the core components since
the api has the ability to send keep alive requests to various services
based on some various kinds trigger. Any suggestions on how to start?

Thanks.

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

**


Hi,

I'm new to tdd and i've read the book growing oo software. I'm trying to
incorporate tdd into a sample project. Basically the project is an api that
allows you to keep-alive various services, basically its a heartbeat. The
book says to start out by designing a skeleton that is enough to get your
application functioning and that which covers the core components. So the
simplest end-to-end test I can think of is to send an http request and make
sure the server received it. How should i structure this test? Should I
have a fake http server and make a request to it and assert that the server
received the request or should I just make a request to any arbitrary
working url and get its return code?

I feel that my test case does not really cover the core components since
the api has the ability to send keep alive requests to various services
based on some various kinds trigger. Any suggestions on how to start?

Thanks.

Hey, Edmund, How are you?

Thanks for calling out the single Assert and the fact that it can never
fail.

I think the first post I ever made to the XP list was something like "how do
you tell when your code is bad?

So I'm studying Code Smells and Refactoring now...

Because you brought it up, I looked at the code. It doesn't look like any
TDD code I've ever done, but what do I know?

So I've recognized "Large Class" which has too many instance variables, and
"Code Duplication."


There's are two "try" sections. They are identical except for the hard coded
primitive (I think that's the right word, is it?)
Here they are:
**
try {
// Use hard-coded 1 for assigned number of task threads.
SjcThreadLocalUtil.setUserId("Tasks [1] Create");
createTasks(1);
clearCache();

SjcThreadLocalUtil.setUserId("Tasks [1] Find");
findTasks(1);
clearCache();

SjcThreadLocalUtil.setUserId("Tasks [1] Update");
updateTasks(1);
clearCache();

SjcThreadLocalUtil.setUserId("Tasks [1] Query");
queryTasks(1);
clearCache();

**
And
try {
// Use assigned number of task threads.
SjcThreadLocalUtil.setUserId("Task [2] Create");
createTasks(2);
clearCache();

SjcThreadLocalUtil.setUserId("Task [2] Find");
findTasks(2);
clearCache();

SjcThreadLocalUtil.setUserId("Task [2] Update");
updateTasks(2);
clearCache();

SjcThreadLocalUtil.setUserId("Task [2] Query");
queryTasks(2);
clearCache();

This smells like Code Duplication to me. Any suggestions on refactoring?
I'm guessing a loop might work, but possibly not in this particular method.

Any suggestions??

Thanks,

Kay Pentecost

So in fact we are talking about designing the user interface of a library (users being other programmers). And concurrently spiking the implementation to get a better idea of what kinds of things you can do. That's more like storyboarding a GUI than coding the guts of an application. Sounds like a fine approach to me.

Only to be clear with words, what you write to drive your API isn't called a test by anyone I've read. It's a driver or a fixture, or a demonstration. Tests are code that decide whether something is correct or not. They pass or fail something. TDD tests are tests in that sense. The "TDD is not about testing" holds because the testing process tries to judge whether an application is correct from a variety of angles while TDD tests aim to create code. It's not testing to Test the code only according to how it was created.

Alan Baljeu

-----Original Message-----
From: testdrivendevelopment@...
[mailto:testdrivendevelopment@...] On Behalf Of Edmund
Schweppe
Sent: Tuesday, June 26, 2012 9:45 PM
To: testdrivendevelopment@...
Subject: Re: Handling duplication was RE: [TDD] Cunningham quote about
test-first


On Jun 26, 2012, at 8:02 PM, Kay A Pentecost wrote:

Hey, Edmund, How are you?

Thanks for calling out the single Assert and the fact that it can never
fail.

I think the first post I ever made to the XP list was something like

"how do

you tell when your code is bad?

So I'm studying Code Smells and Refactoring now...

Because you brought it up, I looked at the code. It doesn't look like

any

TDD code I've ever done, but what do I know?

So I've recognized "Large Class" which has too many instance variables,

and

"Code Duplication."

[ snip ]

This smells like Code Duplication to me. Any suggestions on refactoring?
I'm guessing a loop might work, but possibly not in this particular

method.

Any suggestions??

I spotted four try-finally blocks, three of which appear to be identical
except for the number of tasks. I'd probably first refactor the number of
tasks into a variable, extract the block into its own method, and promote
the variable to a method parameter. then I'd write three JUnit tests that
each call that new method, passing in the appropriate values (1, 2, and
BookingMultiCoreIT.NUMBER_OF_TASKS).

That's assuming, of course, that I didn't first try and find something
meaningful that I could Assert, rather than just store elapsed times in
local variables and dump them to System.out at the very end.

The fourth try-finally block calls the createRecursive(), findRecursive(),
etc. methods rather than the createTasks(), findTasks(), etc. methods. Off
the top of my head, I'm not sure how I'd handle that one; I'd probably
wait until I had a better understanding of what the heck the system under
test was supposed to be doing.


Edmund Schweppe
ed@...





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

Yahoo! Groups Links

-----Original Message-----
From: testdrivendevelopment@...
[mailto:testdrivendevelopment@...] On Behalf Of Edmund
Schweppe
Sent: Tuesday, June 26, 2012 3:16 PM
To: testdrivendevelopment@...
Subject: Re: [TDD] Cunningham quote about test-first

test/info/soaj/sjr/business/facade/BookingMultiCoreIT.html

I'm glad that you found developing that code to be significant (and, I
presume, useful) to you.

I further presume that you did not develop that code using TDD, as there
is only one "test" method in the 635 lines of code, and that one test
method cannot possibly fail. There is only one assertion, and the method
whose return value is being checked has a hardcoded return value of
"true".