Home > Archive > Extreme Programming > March 2004 > Re: TDD: Test-Driven Design or Test-Driven Development?
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Re: TDD: Test-Driven Design or Test-Driven Development?
|
|
| Robert C. Martin 2004-03-18, 6:53 pm |
| On Thu, 11 Mar 2004 11:07:55 +0200, "Vladimir Trushkin"
<NspamOtrushkin@tut.by> wrote:
>It's vital to maintain documentation up-to-date. This is rather the matter
>of granularity how often you will need to support it in contrary to how
>useful it will be for other team members.
>
>In my experience, the biggest benefit from documenting of what you are going
>to do is the ability to share your decisions with others, thus verifying the
>concepts and assumptions you adopted before you started to implement them.
I've never found massive analysis and design documents to be useful
for the long term. They tend to sit on a shelf and collect dust. The
act of writing them, however, has proven useful to me on occasion. It
has forced me, and my team members to think issues through. On the
other hand, I have participated in project where we were able to think
issues through quite well without producing massive documentation. We
simply worked closely together and brainstormed frequently.
In any project I do, I keep the user documentation as current as
possible, as well as a modicum of technical documentation for myself
and my team. These technical docs are lightweight overviews, not in
depth design documents. I find the code works quite nicely once depth
of understanding is required.
I am also a stickler for good clean code. I want the code to *be* the
detailed design document. Therefore I want it to be expressive,
clear, and clean.
| |
| Ilja Preuß 2004-03-18, 6:53 pm |
| Robert C. Martin wrote:
> The
> act of writing them, however, has proven useful to me on occasion. It
> has forced me, and my team members to think issues through. On the
> other hand, I have participated in project where we were able to think
> issues through quite well without producing massive documentation. We
> simply worked closely together and brainstormed frequently.
A bunch of years ago, I "invented" what I know would call "documentation
driven development" - I would write the JavaDoc comments of classes and
methods before implementing them. This was of great help to think about the
responsibilities of a class and discussing it with team members.
Today I find that JUnit tests are even more effective for the same purpose.
I don't any longer write JavaDoc comments for internal use.
Take care, Ilja
| |
| Shane Mingins 2004-03-18, 6:53 pm |
| "Robert C. Martin" <unclebob@objectmentor.com> wrote in message
> In any project I do, I keep the user documentation as current as
> possible, as well as a modicum of technical documentation for myself
> and my team. These technical docs are lightweight overviews, not in
> depth design documents. I find the code works quite nicely once depth
> of understanding is required.
>
Have you come across any good techniques for keeping user documentation in
synch with the code? Just thinking of the DRY principle and wondering how
it would be possible to build the user documentation from the code.
| |
| Universe 2004-03-18, 6:53 pm |
| "Robert C. Martin" wrote:
> I've never found massive analysis and design documents to be useful
> for the long term.
Just "massive" coding, and "massive" stove pipes, and "massive" cul de sacs,
and
"massive" coronary's !:- >
Elliott
| |
| Universe 2004-03-18, 6:53 pm |
| "Robert C. Martin" wrote:
> I've never found massive analysis and design documents to be useful
> for the long term...
As if software engineering generally, everywhere and worldwide, were all
about your "massive", narcissistic, ego-mania.
[Zip, Boom, Bang! :- ]
Elliott
| |
| Vladimir Trushkin 2004-03-18, 6:53 pm |
| "Anthony Williams" <anthony_w.geo@yahoo.com> wrote in message
news:wu60d08p.fsf@yahoo.com...
> "Vladimir Trushkin" <NspamOtrushkin@tut.by> writes:
produce[color=darkred]
for[color=darkred]
Integration[color=darkred]
group[color=darkred]
;)[color=darkred]
>
> I am not entirely sure what your problem is. TDD helps me write tests
(with a
> small t) that help me (as a developer) design the application as I code
it,
> and make changes with a high degree of confidence that I won't break
things
> that already work. This is entirely separate from the Testing (with a
capital
> T) required for QC.
This is definitively not my problem. This is in my nature to point
developers on mistakes within their testing.
> If your QC guidelines require a certain level of Testing, then the QC team
can
> write Tests that ensure the application is sufficiently Tested. If they
can
> reuse my tests as part of their Tests, then so much the better.
Well, well, well... Now QC is responsible for doing Structured testing. So
you prefer someone else to do the job at assuring the quality of results
_your won work_. How common for developers, and how convenient. This reminds
me of "throe over the wall" approach to relationships between QC and
Development.
> The TDD testing done by the developers *does* reduce the chances of a bug
> making it as far as the QC Tests, since many would-be bugs are caught by
the
> developers.
Yes it does, but no one knows to what extent. Besides its application as a
testing technique is inadequate because it doesn't make sure the code
structure is correct whatever path through it is taken.
> IIUC, XP as a methodology has nothing to say about Testing done by the QC
> team, so it neither requires it or precludes it. Consequently requirements
for
> "a decent level of structured testing" don't preclude the use of XP or any
> other methodology, you just define what you mean by "decent level", and
add a
> QC requirement for it.
Some of XPers made me believe that XP has a separate QC. As a software
development methodology it should allow for Quality Management system.
----
Best Wishes,
Vladimir
| |
| Robert C. Martin 2004-03-18, 6:53 pm |
| On Thu, 11 Mar 2004 18:08:37 +0100, "Ilja Preuß" <preuss@disy.net>
wrote:
>Today I find that JUnit tests are even more effective for the same purpose.
>I don't any longer write JavaDoc comments for internal use.
I think we've yet to plumb the capability for tests to act as
documentation. I have found that I can understand code written by
others, or that I wrote months ago much better by reading through the
unit tests. Still, I think there is a place for Javadocs and similar
kinds of design documentation. I'd be lost without the ability to
bring up the API javadocs.
| |
| Robert C. Martin 2004-03-18, 6:53 pm |
| On Fri, 12 Mar 2004 09:12:52 +1300, "Shane Mingins"
<shanemingins@yahoo.com.clothes> wrote:
>"Robert C. Martin" <unclebob@objectmentor.com> wrote in message
>Have you come across any good techniques for keeping user documentation in
>synch with the code? Just thinking of the DRY principle and wondering how
>it would be possible to build the user documentation from the code.
I've not been very impressed with the tools that automatically convert
code into UML. I don't think that anything but a human mind can
organize a diagram to express intent. Therefore I accept the small
violation of DRY in those rare cases when I think a diagram is a
valuable adjunct to the code.
| |
| Ilja Preuß 2004-03-18, 6:53 pm |
| Robert C. Martin wrote:
> On Fri, 12 Mar 2004 09:12:52 +1300, "Shane Mingins"
> <shanemingins@yahoo.com.clothes> wrote:
>
>
> I've not been very impressed with the tools that automatically convert
> code into UML. I don't think that anything but a human mind can
> organize a diagram to express intent. Therefore I accept the small
> violation of DRY in those rare cases when I think a diagram is a
> valuable adjunct to the code.
I don't think UML makes for good *user* documentation - and I doubt that you
think it does. So I guess you are speaking of something else?
Regards, Ilja
| |
| Ilja Preuß 2004-03-18, 6:53 pm |
| Shane Mingins wrote:
> "Robert C. Martin" <unclebob@objectmentor.com> wrote in message
>
> Have you come across any good techniques for keeping user
> documentation in synch with the code? Just thinking of the DRY
> principle and wondering how it would be possible to build the user
> documentation from the code.
A coworker of mine has automated a small part of user documentation:
screenshots. With http://www.jdemo.de/ you can write code snippets which,
for example, open a specific dialog and use an Ant target to automatically
save a screenshot to disk.
Besides that, I actually don't think that user documentation can be derived
from code, as the code doesn't really express how the system is supposed to
be used.
A more promising idea would be to derive user documentation from acceptance
tests, I'd think...
Take care, Ilja
| |
| Leif Roar Moldskred 2004-03-18, 6:53 pm |
| "Shane Mingins" <shanemingins@yahoo.com.clothes> writes:
> Have you come across any good techniques for keeping user documentation in
> synch with the code? Just thinking of the DRY principle and wondering how
> it would be possible to build the user documentation from the code.
It might be useful to look into the tools and techiques used by the
literary programming crowd. Start at
http://www.literateprogramming.com
--
Leif Roar Moldskred
| |
| Shane Mingins 2004-03-18, 6:53 pm |
| "Ilja Preuß" <preuss@disy.net> wrote in message
news:c2rve4$f7a$1@stu1id2.ip.tesion.net...
> A more promising idea would be to derive user documentation from
acceptance
> tests, I'd think...
>
I had that thought also. But then thought that the acceptance test
documents the requirement which does not necessarily express the
functionality. The user documentation seems interested in functionality.
Functionality is found in the code is it not?
Have good w end.
Shane
| |
|
|
| Robert C. Martin 2004-03-18, 6:53 pm |
| On Fri, 12 Mar 2004 10:15:44 +0100, "Ilja Preuß" <preuss@disy.net>
wrote:
>Robert C. Martin wrote:
>
>
>Do you have an example of javadoc you would have been lost without -
>although you had access to the source and unit tests? Would be quite
>interesting...
No, I'm thinking of the standard API. When I want to know how
Tokenizer works, I'd first like to see the javadoc. I will say that
there have been times I've had to write my own unit test for some of
the API elements just to verify whether I understand the javadoc.
| |
| Robert C. Martin 2004-03-18, 6:53 pm |
| On Fri, 12 Mar 2004 10:17:15 +0100, "Ilja Preuß" <preuss@disy.net>
wrote:
>Robert C. Martin wrote:
>
>I don't think UML makes for good *user* documentation - and I doubt that you
>think it does. So I guess you are speaking of something else?
>
Oh, sorry, I thought you meant developer documentation.
| |
| Robert C. Martin 2004-03-18, 6:53 pm |
| On Fri, 12 Mar 2004 23:13:05 +1300, "Shane Mingins"
<shanemingins@yahoo.com.clothes> wrote:
>"Ilja Preuß" <preuss@disy.net> wrote in message
>news:c2rve4$f7a$1@stu1id2.ip.tesion.net...
>acceptance
>
>I had that thought also. But then thought that the acceptance test
>documents the requirement which does not necessarily express the
>functionality. The user documentation seems interested in functionality.
>Functionality is found in the code is it not?
Consider the acceptance tests written for FitNesse
(http://fitnesse.org). These are technical, but they could certainly
be used as fodder for a user document.
| |
| Kevin Cline 2004-03-18, 6:54 pm |
| "Vladimir Trushkin" <NspamOtrushkin@tut.by> wrote in message news:<c2k0jr$1rr$1@news.gngidc.net>...
> "Kevin Cline" <kcline17@hotmail.com> wrote in message
> news:ba162549.0403080921.461873ec@posting.google.com...
> news:<ce7ef1c8.0402071123.2a226bf@posting.google.com>...
> news:<b2v920pctgvpdeumiqofvo1pvgae65crip@4ax.com>...
>
>
> There are two concurrent approaches to the problem. First requires
> documentation to have a look at the concept and test it until it even
> started to be implemented. Another is to build early prototype and
> verify/validate it with tests. Both have their advantages and di vantages.
> Saying that in the first case updating docs is a waste of time is completely
> off track.
In my 25 years of experience, the work spent preparing and updating
documents was largely wasted, because the documents did not make
subsequent maintenance easier. Maybe your experience has been
different. Maybe you have joined projects and found very valuable
documentation in place that increased your productivity. Personally,
I've found that asking the other developers "Where can I find the code
for feature X?" much more efficient than wading through five hundred
pages of obsolete design documents.
| |
| Universe 2004-03-18, 6:54 pm |
| "Shayne Wissler" <thalesNOSPAM000@yahoo.com> wrote:
> "Robert C. Martin" <unclebob@objectmentor.com> wrote:
[color=darkred]
[color=darkred]
[color=darkred]
set[color=darkred]
Correct. This is a basic truth of Relativity theory.
[color=darkred]
create.[color=darkred]
Any Physics textbook will attest to the existence of REAL frames of
reference--not
only for Relativity, but also for classical Galilean time-space mechanics.
[color=darkred]
unphysical.
Sure Einstein did.
The Frame of Reference, and gravity resulting from relative motion concepts
are
fundamental to both Special Relativity (non-accelerated, linear motion), as
well
as General Relativity (accelerated, curvilinear motion).
I suggest rather than "supposing", actually reading text on both forms of
mechanics,
by accepted, and well known physicists like Isaac Asimov, and Martin
Gardner.
Asimov wrote the excellent "Revolutions in Physics" series. Gardner whom
wrote
the popular "Mathematical Recreations" column in Scientific American for
many years,
wrote the top notch textbook "Relativity for the Million". By the
"Million", Gardner meant
intellectuals, who are not physicists, capable of absorbing Relativity, at
least in its main
outlines. Gardner's is a great Relativity book for the educated Physics
layperson.
[While Gardner's will inform lay intellectuals about Relativity, Richard
Feynman's book
"Quantum Electro-Dynamics" does the same for Uncertainty Physics. I highly
recommend
both.]
[color=darkred]
is a real[color=darkred]
Where in my or anyone else's explanation of Relativity frames of reference
has
it been said that a gravitational field is an "arbitrary mathematical
construct"?
Relativity shows that gravity results from relative motions, but there are
objectively
real gravitational waves that are created.
Wissler is stuck on Formal logic that says a thing can be both "A " and "not
A" at the same time.
Wissler despite my explorations of dialectics and objects in comp.object
over many years is still unable to accept dialectical logic where a thing
can be both "A" AND "not A" simultaneously.
Typically one aspect of a dialectical relationship predominates, but
nevertheless objects usually possess contradictions with opposing aspects at
the same time. Relative<=>Absolute
I say that because Wissler thinks that if a thing is relative, there can be
absolute about it. Wissler
fails to see that there can be no relative without the absolute and vice
versa no absolute without
the relative. Even though motion is relative according to frame of
reference, WITHIN a frame
of reference, we can speak about absolute motions, velocities, directions,
accelerations, etc.
While Relativity predominates between frames of reference traveling at or
near the speed of light, Galilean time-space is valid for frames of
reference traveling at non-relativistic speeds
with respect to each other.
Domain context object truth is absolute within the domain context, but often
the truth is different or relative when we talk about another domain
context.
AND THE ABOVE ABOUT DOMAIN CONTEXT TRUTH IS WHERE THE Relativity THREAD
began.
Elliott
--
Global Plans + IID ( Iterative & Incremental Development)
Theory Leads, Practice Verifies
| |
| Universe 2004-03-18, 6:54 pm |
| We should take comfort in two conjoined features of nature: first, that our
world is incredibly strange and therefore supremely fascinating . . .
second,
that however bizarre and arcane our world might be, nature remains
comprehensible to the human mind. ~ Stephen Jay Gould
| |
| Ilja Preuß 2004-03-18, 6:54 pm |
| Robert C. Martin wrote:
> I think we've yet to plumb the capability for tests to act as
> documentation. I have found that I can understand code written by
> others, or that I wrote months ago much better by reading through the
> unit tests. Still, I think there is a place for Javadocs and similar
> kinds of design documentation. I'd be lost without the ability to
> bring up the API javadocs.
Do you have an example of javadoc you would have been lost without -
although you had access to the source and unit tests? Would be quite
interesting...
Thanks, Ilja
| |
| Robert C. Martin 2004-03-18, 6:54 pm |
| On Thu, 18 Mar 2004 19:37:13 -0000, "Paul Campbell"
<p.au.l.ca.mp.b.ell@ob.jectvi.sion.c.o.u.k> wrote:
>
>"Cristiano Sadun" <TAKEcristianoTHISunOUT@hotmail.com> wrote in message
> news:Xns94A08F9C3EB56cristianounhotma
i@195.131.52.135...
>
>Well lets say we have a non sharable resource access and we want to
>force ourselves to make it thread safe having a test that fails only when
>the offending code block is accesed by more than one thread.
>
>If order to get such a failing test we have to create an artificial RP inside
>this code block. So we have to plonk an instrumentation insertion point
>with right in the middle of my critical code block - exactly the point where
>I would want to avoid any unnecesary logic, especially logic that changes
>the behaviour between live and under test running.
Yes, there is an observer effect. The act of testing causes some
change. The alternative, however, is not to test -- and that seems
unacceptable to me.
The observer effect can be minimized by using a bit of polymorphic
behavior. Our RP can actually be a do-nothing class that is
overridden by the unit test to count events. So, although the RP must
exist in the code, it can be minimally intrusive.
There may be times when even this minimal intrusion is too much. In
that case you'll have to use an external approach to testing. Ward
Cunningham once tested a video controller algorithm by creating a
framework in Java that simulated the system. He was able to get it to
work, test-first, in the framework environment, and then had the
framework generate the DSP code. This is an interesting approach
because it virtually eliminates the observer effect. Instead you
control time and space and observe the effects from the outside.
(You can find a description of Ward's work somewhere on c2.com)
| |
| Dmitry A. Kazakov 2004-03-19, 1:17 pm |
| On Thu, 18 Mar 2004 14:41:09 -0600, Robert C. Martin
<unclebob@objectmentor.com> wrote:
>On Thu, 18 Mar 2004 19:37:13 -0000, "Paul Campbell"
><p.au.l.ca.mp.b.ell@ob.jectvi.sion.c.o.u.k> wrote:
>
>
>Yes, there is an observer effect. The act of testing causes some
>change. The alternative, however, is not to test -- and that seems
>unacceptable to me.
The alternative to have the resource a protected object, which need
not to be tested. Because it is statically known to be thread-safe.
--
Regards,
Dmitry Kazakov
www.dmitry-kazakov.de
| |
| Cristiano Sadun 2004-03-19, 1:17 pm |
| "Paul Campbell" <p.au.l.ca.mp.b.ell@ob.jectvi.sion.c.o.u.k> wrote in
news:1079638634.9621.0@nnrp-t71-02.news.uk.clara.net:
> Well lets say we have a non sharable resource access and we want to
> force ourselves to make it thread safe having a test that fails only
> when the offending code block is accesed by more than one thread.
>
> If order to get such a failing test we have to create an artificial RP
> inside this code block. So we have to plonk an instrumentation
> insertion point with right in the middle of my critical code block -
> exactly the point where I would want to avoid any unnecesary logic,
> especially logic that changes the behaviour between live and under
> test running.
I'm not sure I understand. I would go by creating a test which externally
attempts to use the resource R concurrently - creating two threads T1 and
T2 and timing their access to ensure that the second will try to access
the R while the first is still doing so.
I want to force:
T1 -+----------------------------------------------->
|
|
T2 -(--------+-------------------------------------->
| |
V V
R -XXXXXXXXXXXXXXXXXXX----------------------------->
t0 t1 t2
that, is R is serving T1 between t0 and t2, and T2 attempts to use R at
t1, where t0 < t1 < t2. At time t1, R is executing a certain step S.
In order to do so - if that's what you refer as artificial RP - I need to
instrument R so that I can control t2, typically introducing one or more
artificial delays. This is the kind of instrumentation you need most
often.
Otherwise t0 and t1 are completely controllable by the test code - t0 is
trivial, but I need to think which different values in t1 may make a
difference, and write tests for them. Often this is not a real issue, as
I can determine (reasoning functionally) which steps executed by R
between t0 and t2 are or are not supposed to be atomic. In the worst
case, the timing of each step in R usage may need to be instrumented.
That depends on what is precisely that you are implementing in R (let's
imagine the resource is a file, the threaded functionality is file access
and elaboration, and its steps are "open" "read" etc. T1 and T2 would
invoke the elaboration method at differnt times, tweaking the delays so
that the RP occurs at different steps). As Robert said, the actual coding
of such instrumentation can be realized with OO techniques so that its
functional impact is null or minimal (of course there will be *timing*
impact. That's why this technique cannot be used to test systems where
the precise time of a step is an issue, as opposed to just the mutual
order of execution of the invocation and/or the various steps).
If R is not correctly synchronized, one of said tests will fail - the
final result will not be the expected one (since we completely control
the tests input parameters we can ensure that).
Then I change R code (with just synchronization primitives) so that no
test fails. For example, if you have critical regions, a way is to make
the entire access a critical region, then de-criticize subblocks for
optimization.
In production, the instrumentation may be disabled; or better left there
for "debug mode" control - which I find useful for other reasons (namely,
component failure profile seems to depend also on their deployment
context, there were some papers back in the CACM some years ago.. so you
basically are guaranteed that you'll still need to do some tweaking once
the component is in place - another good reason for integrating as early
as possible).
--
You dont know what to do when you dont know what you're doing.
[url]http://space.tin.it/computer/cun[/url]
| |
| Paul Campbell 2004-03-19, 1:17 pm |
|
"Robert C. Martin" <unclebob@objectmentor.com> wrote in message news:ov1k50tg9gniuu2spn3840vtemhv46lt9g@
4ax.com...
> Yes, there is an observer effect. The act of testing causes some
> change. The alternative, however, is not to test -- and that seems
> unacceptable to me.
The other alternative is for me and my pair to apply our static
analytical skills and conclude "lets just put a synchronize around this
block (or use a known thread safe equivalent of the resource) and
be done with it". IME (and I *have* actually tried to do
insertion style concurrecy testing ..) this is prefereable to having to
struggle with a convoluted tests involving creation of multiple threads
with wait-notify communication between the insertion point and the
other injected thread - all to test a small simple purely linear bit
of code.
Paul C.
| |
| Cristiano Sadun 2004-03-19, 1:17 pm |
| "Paul Campbell" <p.au.l.ca.mp.b.ell@ob.jectvi.sion.c.o.u.k> wrote in
news:1079693746.1592.0@nnrp-t71-02.news.uk.clara.net:
>
> "Robert C. Martin" <unclebob@objectmentor.com> wrote in message
> news:ov1k50tg9gniuu2spn3840vtemhv46lt9g@
4ax.com...
>
>
> The other alternative is for me and my pair to apply our static
> analytical skills and conclude "lets just put a synchronize around
> this block (or use a known thread safe equivalent of the resource) and
> be done with it". IME (and I *have* actually tried to do
> insertion style concurrecy testing ..)
The result is exactly that. The trick is knowing why you're doing it, so
that you can apply the same idea in less obvious cases.
> this is prefereable to having
> to struggle with a convoluted tests involving creation of multiple
> threads with wait-notify communication between the insertion point
> and the other injected thread - all to test a small simple purely
> linear bit of code.
It just *appears* convoluted - that was the message. It aint in practice.
When u're putting your syncrhonized block, you're just doing all the steps
- thinking where the RPs are and how they may interact etc - mentally.
Then the test itself is usually a few lines of code.
But comes *extremely* useful when you add or change functionality tomorrow.
--
You dont know what to do when you dont know what you're doing.
[url]http://space.tin.it/computer/cun[/url]
| |
| Paul Campbell 2004-03-19, 1:17 pm |
|
"Cristiano Sadun" <TAKEcristianoTHISunOUT@hotmail.com> wrote in message
news:Xns94B177EA9D2F3cristianounhotma
i@195.131.52.135...
> "Paul Campbell" <p.au.l.ca.mp.b.ell@ob.jectvi.sion.c.o.u.k> wrote in
> news:1079638634.9621.0@nnrp-t71-02.news.uk.clara.net:
>
>
> I'm not sure I understand. I would go by creating a test which externally
> attempts to use the resource R concurrently - creating two threads T1 and
> T2 and timing their access to ensure that the second will try to access
> the R while the first is still doing so.
Youve got to be kidding me right ??. There is no way that you can reliably
eliminate false positives from such a non-deterministic approach. False
positives would totally undermine TDD even if they were "OK" for
other sorts of testing.
The *only* way to make this deterministic is to force one thread to artificially
stop in the critical region, and for this stoppage to be the trigger event
that cuases the test to inject the second thread.
Paul C.
| |
| Cristiano Sadun 2004-03-19, 1:17 pm |
| "Paul Campbell" <p.au.l.ca.mp.b.ell@ob.jectvi.sion.c.o.u.k> wrote in
news:1079699018.3136.0@nnrp-t71-02.news.uk.clara.net:
> Youve got to be kidding me right ??. There is no way that you can
> reliably eliminate false positives from such a non-deterministic
> approach. False positives would totally undermine TDD even if they
> were "OK" for other sorts of testing.
The point is exactly in enforcing the order of calls. Where would the non-
determinism be?
--
You dont know what to do when you dont know what you're doing.
[url]http://space.tin.it/computer/cun[/url]
| |
| Robert C. Martin 2004-03-19, 1:17 pm |
| On Fri, 19 Mar 2004 09:35:05 +0100, Dmitry A. Kazakov
<mailbox@dmitry-kazakov.de> wrote:
>The alternative to have the resource a protected object, which need
>not to be tested. Because it is statically known to be thread-safe.
Has this aircraft ever flown before?
No, but trust me, we've statically proven that it will fly.
| |
| Paul Campbell 2004-03-19, 1:17 pm |
|
"Cristiano Sadun" <TAKEcristianoTHISunOUT@hotmail.com> wrote in message
news:Xns94B188D6DA301cristianounhotma
i@195.131.52.135...
> "Paul Campbell" <p.au.l.ca.mp.b.ell@ob.jectvi.sion.c.o.u.k> wrote in
> news:1079699018.3136.0@nnrp-t71-02.news.uk.clara.net:
>
>
> The point is exactly in enforcing the order of calls. Where would the non-
> determinism be?
Order is not enough. To eliminate false positives the threads *must*
both be simultaniously "present" at a set point in the critical code block.
The only way you can *guarantee* that this occurs is to 1) inject
the first thread 2) stop the first thread at the RP 3) inject the second
thread.
If you omit (2) then there is always the risk that the first thread exists the
critical section before the other thread gets there, or vice versa.
Unless you know precisely how long each thread is going to take to
execute each line of code (including such factors as OS scheduler
behaviour) then you have a non deterministic situation.
Paul C.
| |
| Robert C. Martin 2004-03-19, 1:17 pm |
| On Fri, 19 Mar 2004 10:55:46 -0000, "Paul Campbell"
<p.au.l.ca.mp.b.ell@ob.jectvi.sion.c.o.u.k> wrote:
>
>"Robert C. Martin" <unclebob@objectmentor.com> wrote in message news:ov1k50tg9gniuu2spn3840vtemhv46lt9g@
4ax.com...
>
>
>The other alternative is for me and my pair to apply our static
>analytical skills and conclude "lets just put a synchronize around this
>block (or use a known thread safe equivalent of the resource) and
>be done with it". IME (and I *have* actually tried to do
>insertion style concurrecy testing ..) this is prefereable to having to
>struggle with a convoluted tests involving creation of multiple threads
>with wait-notify communication between the insertion point and the
>other injected thread - all to test a small simple purely linear bit
>of code.
Well, yes. However, in your original post you asked how you'd write a
test:
[color=darkred]
....So I assumed that you had already rejected the idea of using a
critical section for some reason.
| |
| Dmitry A. Kazakov 2004-03-19, 1:17 pm |
| On Fri, 19 Mar 2004 08:25:54 -0600, Robert C. Martin
<unclebob@objectmentor.com> wrote:
>On Fri, 19 Mar 2004 09:35:05 +0100, Dmitry A. Kazakov
><mailbox@dmitry-kazakov.de> wrote:
>
>
>Has this aircraft ever flown before?
Yes, what we are doing is painting its fuselage in a new color...
>No, but trust me, we've statically proven that it will fly.
Do you write a test to check whether each byte of the code generated
by the compiler is correct?
If yes, do you have another to check whether CPU processes all the
machine instruction as expected?
If yes, what about electrons and quantum physics? How can we trust
them without a test written in Smalltalk?
--
Regards,
Dmitry Kazakov
www.dmitry-kazakov.de
| |
| Paul Campbell 2004-03-26, 11:50 pm |
|
"Robert C. Martin" <unclebob@objectmentor.com> wrote in message news:lq0m509tfd440fa3q5r5eh6q9msgd9hu88@
4ax.com...
> On Fri, 19 Mar 2004 10:55:46 -0000, "Paul Campbell"
> <p.au.l.ca.mp.b.ell@ob.jectvi.sion.c.o.u.k> wrote:
>
>
> Well, yes. However, in your original post you asked how you'd write a
> test:
It was implicit that I was asking "how can I write a test that is proportionate
in terms of complexity and effort to the functionalisy under test". I think its quite
clear that this discussion is occuring in the context of practicality and return on
invested effort rather than absolute theoretical possibilities.
Paul C.
| |
| Robert C. Martin 2004-03-26, 11:50 pm |
| On Mon, 22 Mar 2004 12:22:08 -0000, "Paul Campbell"
<p.au.l.ca.mp.b.ell@ob.jectvi.sion.c.o.u.k> wrote:
>
>"Robert C. Martin" <unclebob@objectmentor.com> wrote in message news:lq0m509tfd440fa3q5r5eh6q9msgd9hu88@
4ax.com...
>
>It was implicit that I was asking "how can I write a test that is proportionate
>in terms of complexity and effort to the functionalisy under test". I think its quite
>clear that this discussion is occuring in the context of practicality and return on
>invested effort rather than absolute theoretical possibilities.
Then let me assure you that I have written the kind of test that I
described as a purely pragmatic way of identifying, isolating, and
eliminating a race condition.
| |
| Paul Campbell 2004-03-26, 11:50 pm |
|
"Robert C. Martin" <unclebob@objectmentor.com> wrote in message news:duut501gquv8uclv4doctrffq6uielbjgl@
4ax.com...
> Then let me assure you that I have written the kind of test that I
> described as a purely pragmatic way of identifying, isolating, and
> eliminating a race condition.
So have I , and I concluded that the next time I faced that situation I would
just bung a synchronised block around it and spend the half day that I saved
doing something of more value.
Anyhow lets agree to differ on the issue of testing race conditions. What about the
concurreny problems that arnt race conditions e.g. using static store instead of heap/
stack store, using unsafe containers or libraries, calling non-thread safe system calls
etc - I'm I supposed to write tests to force myself not to do all of these things too ?.
Lets take the first one: using static data, I presume you never use dynamic store
in the first cut of any threaded code you write - you write it using statics only
and then make your failing tests pass by switching to heap/stack ?.
Paul C.
| |
| Kevin Cline 2004-03-26, 11:50 pm |
| vertleyb@hotmail.com (Arkadiy Vertleyb) wrote in message news:<2f56064a.0403051331.3372e80c@posting.google.com>...
> Cristiano Sadun <TAKEcristianoTHISunOUT@hotmail.com> wrote
>
>
> The particular challenge, IMO, is that one would like to view threads
> as an ortogonal issue (an aspect if you preffer). And one would like
> to manage complexity by testing (and designing, and thinking about)
> one thing at a time. To test the multithreaded code I have to think
> about how two or more threads communicate with each other, which is
> not impossible, but a whole lot more complicated. If I have to design
> for testability, I will probably have to mix these aspecs not only in
> my brain, but also in the code...
I try hard to avoid mixing them in the code. I try to collect all the
synchronization logic for a partucular datum into a single class, then
attempt to prove the correctness of that class so that the rest of the
code can be written without worry about synchronization. Then I test
the class for adequate performance. If the performance is inadequate
then I try to refactor the class for better performance.
| |
| Robert C. Martin 2004-03-26, 11:50 pm |
| On Mon, 22 Mar 2004 18:31:25 -0000, "Paul Campbell"
<p.au.l.ca.mp.b.ell@ob.jectvi.sion.c.o.u.k> wrote:
>
>"Robert C. Martin" <unclebob@objectmentor.com> wrote in message news:duut501gquv8uclv4doctrffq6uielbjgl@
4ax.com...
>
>
>So have I , and I concluded that the next time I faced that situation I would
>just bung a synchronised block around it and spend the half day that I saved
>doing something of more value.
I can sympathize with that view.
>Anyhow lets agree to differ on the issue of testing race conditions. What about the
>concurreny problems that arnt race conditions e.g. using static store instead of heap/
>stack store, using unsafe containers or libraries, calling non-thread safe system calls
>etc - I'm I supposed to write tests to force myself not to do all of these things too ?.
No, you are supposed to know better. If you make a mistake and do the
wrong thing, then it would probably be wise to write a test that
proves that your problem has to do with an unsafe variable, and then
make the test pass by making the variable safe.
>Lets take the first one: using static data, I presume you never use dynamic store
>in the first cut of any threaded code you write - you write it using statics only
>and then make your failing tests pass by switching to heap/stack ?.
No. (the following is friendly, not derisive) Nor do I write code
with lots of gotos in them and then write tests that force me to take
the gotos out.
Did our communication break down *that* far?
| |
| Paul Campbell 2004-03-26, 11:50 pm |
|
"Robert C. Martin" <unclebob@objectmentor.com> wrote in message news:eomu5051o6ue7vpo2rqf461i4uqgknp81c@
4ax.com...
> On Mon, 22 Mar 2004 18:31:25 -0000, "Paul Campbell"
> <p.au.l.ca.mp.b.ell@ob.jectvi.sion.c.o.u.k> wrote:
>
>
> I can sympathize with that view.
>
>
> No, you are supposed to know better.
Well I would claim that I "know better" than to omit a synchronised block
around obviously unsafe code. Seems to me that this is a judgement call as
to whether something falls into the "just do it becase you know its right" vs
"do it because the tests force you".
> If you make a mistake and do the
> wrong thing, then it would probably be wise to write a test that
> proves that your problem has to do with an unsafe variable, and then
> make the test pass by making the variable safe.
I agree to a point but then you only have a test against the safe use of that
one variable with no absolute protection that you havnt (or wont) make the
same mistake somewhere else. For me the danger of such a wide-net-with
-thin-strands test coverage is that it leads to a false sence of safety. If I
know I have effective no runtime testing of threading issues then that
puts the onus clearly on a solid static analysis.
Paul C.
|
|
|
|
|